Crashing into the Technological Wall

Imagine finding the perfect security solution for your corporate VPN. It is low cost or free, it has been vetted through the process of nearly two decades of open source review, and it is supported on all of your company’s operating systems. You can integrate an internal certificate authority, complete with certificate revocation lists, and include PAM single sign-on authentication modules for a full solution that appears to satisfy your information security policy’s confidentiality, integrity, and availability requirements.

Imagine, then, that your beta test discovers that it can’t reliably scale beyond more than a dozen active users.

OpenVPN was developed over many years through the efforts of talented contributors. It is one of only a handful of reputable free or open source solutions addressing the VPN market – A virtual network, often over the internet, to link your corporate network with remote workstations in a secure manner. VPN software, much like other security software, benefits strongly from long-term community acceptance and review. The more review that security software has, the more robust it is thought to be at resisting known types of security intrusions. The OpenVPN project fits this bill handily. However, other important considerations were neglected throughout development.

In the mid 2010s, industry migrated to a minimum of 2048-bit RSA public key cryptography, along with a strong preference for 256-bit symmetric encryption. The expansion of data-intensive or latency-sensitive use cases, such as video, teleconferencing, and the transfer of large data sets vastly increased the load that VPN server solutions are required to handle. Parallel to the tightening of minimum security requirements, state-of-the-art computer architectures continued a decade long trend towards multi-threaded and multi-processor systems in pursuit of increased performance. Raw single processor performance became a non-meaningful metric, as gains in single-threaded loads paled in comparison to gains offered through heterogeneous and homogeneous multi-processor systems. The OpenVPN server, a monolithic C application, runs within a single process context and is not multi-threaded. Benefits from the advances in multi-processor systems cannot be realized within an OpenVPN server process without running multiple OpenVPN instances (often one per end user, each instance hosted on a different TCP or UDP port) and setting up complex routing rules within the operating system.

Session key negotiation and the transfer of large volumes of data re the two main load drivers on a VPN server. As security requirements tighten, more and more of a single processor core’s execution time is spent on these tasks in an OpenVPN instance. The monolithic design leads to key renegotiation from one user impacting the performance of all other logged in users. While this may not be noticeable for 2 or 3 end users, at some point the OpenVPN server instance will reach a point where the performance problems or scaling issues will render it unfit for certain use cases. Such performance issues may become more the norm in the near future as industry further tightens security expectations to a minimum of 3072-bit RSA public keys.

Addressing the shortcomings of a legacy design can be expensive or even impossible. This is true whether that legacy design is due to a lack of discernible architecture, the desire to retain tried-and-tested designs for security reasons, or not having a unified set of standards and practices among contributors. Community driven development excels in small, incremental steps, as described on the OpenVPN community wiki. Large coordinated architectural evolution, on the other hand, is extremely difficult under a development model that lacks a strong central authority.

The OpenVPN project contributors are fixing this. Efforts on the OpenVPN 3.0 rework have been ongoing since at least the May 2010 road map meeting. Their task is neither small nor trivial, but given enough resources and time they will certainly reach feature parity with the legacy code. Their burden is also not one to carelessly ignore, as it extends frighteningly beyond mere technical challenge. The reluctance of developers to change tried-and-tested code is a triviality compared to larger market forces. Who is to say that industry would ever embrace a programmer’s rework at all? Wouldn’t the vast majority of end users stick with the older, more widely tested version? Without a plan to convincingly demonstrate the security of a new re-designed version market rejection of the new product is more likely than not. Once the old monolithic OpenVPN application reaches its absolute end of market usefulness, what edge would a new but non-vetted OpenVPN application have over any other more mature, more well-tested solution?

Projects that seek to have an expected lifetime far into the future must be built to scale and evolve in as many potential paths that computer hardware and software development might reasonably take. It isn’t even required for the long-lived project to immediately make use of features like multi-threading. Rather, the project must be designed and built around the possibility of multi-threading becoming the only way to increase performance or to alleviate scaling issues. Tried-and-tested software development truths, such as maintaining high cohesion and low coupling between components, adequate separation of concerns between modules, the proper documentation of system architecture, and enforcement of adequate standards are often enough to make transitions such as the one faced by the OpenVPN project significantly less painful.

Provided, of course, that this guidance is observed right from the project start, as the case in all of Baseline Softworks, this lesson is sincerely taken to heart, and all projects are approached with future-proofing and industry changes in mind.