Changes between Initial Version and Version 1 of DataChannelOffload/WhatChanges

Timestamp:

05/04/23 21:24:02 (12 months ago)

Author:

Antonio Quartulli

Comment:

--

DataChannelOffload/WhatChanges

@@ +1 @@
+= Data Channel Offload: what changes
+
+== Before DCO
+The picture below depicts how data packets flow on a generic OpenVPN server:
+
+[[Image(no-dco.png)]]
+
+From the application, packets enter the kernel networking stack through ''tun0'', but then they are immediately sent back to userspace, so that the OpenVPN process can decide where they are headed to and then encrypt them. At this point packets are sent back to the networking stack of the kernel and finally to the Internet.
+On the way back the sequence of events is the same but in the opposite direction.
+
+There are two main disadvantages with this approach:
+1. data packets enter and leave the kernel twice;
+1. all client traffic is handled by the single-threaded OpenVPN process.
+
+Both have been known limiting factors for OpenVPN2.x performance.
+Running OpenVPN on a beefy CPU has often been the answer in the past in order to push the throughput as high as possible, but due to continuously increasing line rates this approach is simply not feasible anymore.
+
+== Introducing DCO
+To overcome the limitations described in the section above we have developed ''ovpn-dco'', a Linux kernel module designed to work back-to-back with the OpenVPN userspace software.
+When a VPN connection is established, being it on a client, on a server or on a p2p instance, the userspace process will first perform the usual handshake and will then pass the data channel parameters to ovpn-dco using its ''NetLink'' interface, so that it can take over from there. At this point, data packets are all handled in kernelspace and are never sent up to the userspace process.
+
+The picture below helps to visualize the difference with to the basic scenario shown above:
+
+[[Image(dco.png)]]
+
+Context switches are therefore reduced to the minimum and packet processing can take advantage of the kernel concurrency model.
+The two main OpenVPN functions, crypto and routing, are now implemented in kernel using the provided API.
+For what concerns routing, the system routing table is directly used to understand if packets have to be re-routed directly to another peer (i.e. client-to-client mode), without the need to ask the userspace process at all.
+
+OpenVPN in userspace is still in charge of handling the control channel, where all the complex and less throughput-critical operations take place. This is considered an advantage as it allowed to keep the complexity of the ovpn-dco kernel module to the minimum and thus reduce the attack surface. This means that the TLS handshake, data channel key (re-)negotiations and parameters exchange is still performed in userspace.
+
+It should be noted that embedded devices, like small routers, will probably benefit considerably from DCO. 
+
+The ovpn-dco source code for Linux is currently available at the following repository: https://github.com/OpenVPN/ovpn-dco
+
+Please note that **OpenVPN 2.6 or greater** is required in order to use ovpn-dco.