Keywords

1 Introduction and Motivation

Complex industrial production processes, as of today, are highly computerized and involve a large number of interconnected devices. Yet, interconnection of production environments as a driver for highly optimized production processes is predicted to continue in the future, thus allowing for novel business models often summarized by the visionary term of a “fourth industrial revolution” [11].

Within this vision of heavily interconnected “smart factories” [19], a key element is remote access to the interconnected components involved in production processes. A robust remote access framework not only allows to reduce costs by reducing on-site maintenance and incident durations but also is an enabler for various machine-to-machine interaction scenarios. Malicious use of remote access frameworks, however, must be prevented by enforcing secure authentication and encryption facilities, which should be flanked by an anomaly detection framework. IPsec [13] and openVPN [1] are well-established solutions to achieve the first goal on the network layer; the second goal, despite being out of the scope of this work, can be achieved on the same cloud infrastructure by inspecting traffic that is forwarded by a centralized VPN endpoint between the involved entities.

This paper evaluates the suitability of the aforementioned VPN technologies for such a massive IIoT remote administration architecture and is organized as follows: Sect. 2 gives an overview of the related work. Section 3 describes our evaluation platform and compares involved IPsec and openVPN protocol properties. In Sect. 4 we present an empirical performance evaluation of the core cloud component for both protocols. Section 5 discusses the results we obtained and concludes this work.

2 State-of-the-Art and Related Work

The wide availability of Internet Protocol (IP) based packet switched networks, in conjunction with IP-based VPN protocols allowing to tunnel traffic to and from different private domainsFootnote 1, allows for flexible remote access setups. Nowadays, there exists a variety of VPN protocols to tunnel network or data link layer traffic, yet many of them provide little to no security [14]. With an increasing awareness of security requirements in the internet domain, the most widely used VPN technologies therefore either comply with the IPsec standard or use a Transport Layer Security (TLS) [9] framework, as openVPN does.

In the context of IIoT scenarios involving thousands of connected devices, the performance of VPN technology is very important. A comparison of maximally achievable bandwidths and response times using IPsec and openVPN was performed by Kotuliak, Rybár, and Truchly [15] with IPsec outperforming openVPN. Migault et al. analysed processor overheads of different IPsec and cipher suite operation modes and observed significant performance improvement upon activation of hardware acceleration for encryption  [16].

Most related work however focuses on evaluating performance in bidirectional VPN setups and thus only partly applies for the remote access platform we will present in Sect. 3. Our contribution consists in a performance evaluation of a remote access platform taking the role of a trusted intermediary in secure tunnelling scenarios for the IIoT.

3 Platform Architecture

Figure 1 depicts our evaluation architecture for secure, session-based end-to-end tunnelling between entities located in disjoint private network zones A, B, each isolated by at least one firewall and/or Network Address Translation (NAT) [20] layer. An entity in this context represents any IP addressable device. The architecture’s core component is a cloud platform trusted by the operators of both private networks, which consists of:

  • a session database that contains all scheduled tunnelling events,

  • a VPN endpoint that provides encryption and authentication facilities,

  • a routing engine that forwards incoming packets to the respective recipient.

The cloud platform is located in zone C and must be reachable from the private zones. Tunnels are established by the entities in the private subnets, traffic within the remote access tunnel is therefore always directed to and originated from the platform’s VPN endpoint, minimizing firewall configuration effort for operators of the respective private zones.

The platform is not limited to traffic forwarding tasks. An important architectural property lies within traffic being available in decrypted plain-text inside the platform, which we deem beneficially in the context of data aggregation and anomaly detection scenarios as described in [10]. Other processing scenarios such as accounting and monitoring are conceivable. Note that the architecture does not break with application layer security entities may employ to prevent deep packet inspection within the platform.

Fig. 1.
figure 1

Platform and test-bed architecture

Full size image

In the context of these remote access scenarios, we deem high relevance to the performance of the platform’s VPN endpoint in high traffic load conditions and a large number of connection attempts. From a cryptographic point-of-view, there exist various optimizations [7] which allow for fast cryptographic processing of VPN traffic. Nonetheless, different implementation approaches of IPsec and openVPN introduce overheads: openVPN encrypts and decrypts VPN traffic in user space and uses TUN/TAP interfaces to interact with system space routines responsible for actual traffic dispatching via physical network interfaces; session keys are exchanged using a TLS handshake [17]. IPsec traffic, in contrast, is processed by system space routines based on traffic selection and session key container structures called Security Associations (SA). SAs can be setup in the system space using the Internet Key Exchange (IKE) [12] protocol that allows for session key exchange with a reduced number of messages in comparison with the TLS handshake.

Given these considerations and due to the fact that switching from user to system space and vice versa introduces a context switching overhead, we expect IPsec to perform more efficiently under heavy traffic load conditions as it should not be subject to context switching overhead. Yet, both IPsec/IKE and openVPN should provide similar performance when confronted with a large number of key exchange requests.

4 Experimental Performance Evaluation

In order to verify our assumptions, we provide two separate evaluations of the performance of the central platform depicted by Fig. 1. The first measurement targets at the maximum achievable platform throughput that can be realized with openVPN and IPsec and compares the resulting CPU utilization. The second measurement evaluates the platform’s CPU utilization for both VPN endpoints upon being confronted with a large number of key exchanges. While maximum throughput provides a good performance measure in a highly active network, key exchange performance is relevant in the context of massively interconnected IoT devices where connections are established and closed frequently.

We use an evaluation test-bed consisting of both virtual and physical entities in the private zones and a virtualized central platform. NAT/Firewall layers are also virtualized with the help of isolated kernel network namespaces. The virtual entities use the QEMU [3] virtualization engine with each entity allocated a dedicated CPU core (Intel Core i7-6700K) and a Virtual/IO-Network device that provides link speeds in the range of the underlying system’s PCI Bus, in our case 25 GBit/s. It should be noted however that, due to the architectural approach of routing all traffic within the platform, the maximum theoretically achievable end to end bandwidth is only half the link bandwidth, thus 12,5 GBit/s. Nonetheless, this setup allows us to efficiently stress the central platform without needing to deploy hundreds of IIoT devices.

openVPN as well as the strongSwan [4] IPsec suite were evaluated using the AES [5] symmetric cipher in Cipher Block Chaining (CBC) mode with 128-Bit key size in conjunction with HMAC-SHA256 [6] as PRF and for integrity checking. The AES algorithm was selected with respect to AES NI hardware acceleration available in the testbed. Nonetheless, with a measured maximum AES en-/decryption rate of 1.5 GB/s, we ensured that the CPU, not the link, formed the platform’s bottleneck. All CPU and network metrics were recorded on the central platform and evaluated using the Performance Co-Pilot open source software suite [2].

4.1 Maximum Throughput

Figure 2 shows the maximum platform throughput achieved for openVPN and IPsec and highlights that IPsec clearly outperforms openVPN in this respect. The main reason can be recognized from Fig. 3a, which shows the CPU partly running in user, kernel and irq. irq mode handles interrupt routines required when switching from user to kernel mode and vice-versa, but in Linux systems also performs IPsec packet processing. This is visualized in Fig. 3b, which highlights that IPsec processing does not trigger expensive context switches and confirms our previous implications.

Fig. 2.
figure 2

Maximum platform throughput achieved by IPsec and openVPN

Full size image

4.2 Key Exchange

In order to compare the platform’s key negotiation performance for openVPN and strongSwan, we repeatedly initiated tunnel initiation floods originating from a total of four entities towards the openVPN platform endpoint. After successful key exchange, tunnels were closed immediately. We determined a maximum frequency \(f_{\max } = 0.04\) s where all key exchanges were still successful. Figure 4a shows a 60 s key exchange flood towards the platform’s openVPN endpoint. Processing mostly occurs in user space, which is what we expected. However, one easily observes the remarkable portion of overall idle CPU time frames, which we can only suspect to be caused by openVPN implementing an internal key exchange rate limiter not known to us.

Fig. 3.
figure 3

Platform CPU utilization during throughput measurement

Full size image

To provide better comparability, we flooded strongSwan using the same parameters. Figure 4b shows that strongSwan deals more efficiently with the key exchange, despite often switching between user and kernel mode which most likely results from installing negotiated IKE and IPsec SAs in the respective kernel structures.

Fig. 4.
figure 4

Platform CPU utilization during key exchange flood at \(f_{\max }\) from four entities

Full size image

5 Conclusion and Outlook

In this paper, we presented a scalable architecture that is able to flexibly interconnect heterogeneous IIoT entities located within segmented and highly firewalled environments. We therefore focused on the widespread and well-known openVPN and IPsec tunnel protocols which not only provide good security mechanisms but also are able to carry legacy protocols, which is extremely important in industrial contexts. Our work gives abstract estimates on their packet processing and key exchange performance, which are widely confirmed by our empirical measurements. Both theoretical and empirical results strongly suggest that in case of a critical performance, either imposed by throughput or by key exchange rate requirements, IPsec is favourable over openVPN. A promising approach of an IKEv2 mediation server that mediates direct IPsec host-to-host connections has been proposed by [8] and would even increase IPsec performance in similar architectures.

These performance parameters however, do not denote all aspects of both protocols. Although openVPN suffers from weak performance, its very simple configuration by far outperforms IPsec complexity and possible resulting security issues on the other hand. The simple portability of openVPN additionally makes it more attractive in certain situations.

While in the future, remote assistance protocols might arise that integrate more specifically with the IoT and IIoT specifically, we have shown that state of the art VPN solutions can provide a scalable bridging technology that enables end-to-end tunnelling for legacy as well as novel devices.