VPN Solution Benchmarking for Endpoints Under Fast Network Mobility

FACULDADEDE ENGENHARIADA UNIVERSIDADEDO PORTO

VPN solution benchmarking for endpoints under fast network mobility

João Francisco

Mestrado Integrado em Engenharia Eletrotécnica e de Computadores

Supervisor: Ana Aguiar Second Supervisor: António Damião Rodrigues

July 25, 2018 c João Francisco, 2018 Resumo

Esta dissertação foi proposta pela Veniam, uma start-up focada no desenvolvimento de redes veic- ulares. Fornecer conectividade em movimento sobre diferentes tecnologias (DSRC, Wi-Fi, ou 4G LTE) mantendo uma boa qualidade de experiência para os utilizadores é uma tarefa desafiante. O uso de VPNs facilita a gestão da rede, colocando os clientes logicamente numa mesma rede local. Isto pode ser usado para controlo remoto simplificado, e para esconder mudanças na rede física (novo ponto de acesso, novo endereço IP) de serviços e aplicações. Podem acrescentar também segurança, na forma de encriptação e autenticação. As soluções VPN são geralmente apropriadas para resolver o problema de conectividade para clientes estacionários, equipados com capacidade de computação razoavelmente elevada. No entanto, as VPNs falham em cenários móveis, quebrando as ligações ponta-a-ponta quando os clientes trocam de ponto de acesso à rede. Adicionalmente, a criptografia avançada e o peso extra do protocolo resultam em soluções VPN exigentes ao nível de poder de computação no lado do cliente. Aplicar estas soluções nos dispositivos em movimento, de baixos recursos, das frotas inteligentes da Veniam resulta num serviço fortemente degradado. Nesta dissertação, diferentes soluções VPN serão estudadas e comparadas, com o objetivo de selecionar uma solução adequada ao caso de uso da Veniam. Para cada implementação, a degradação do throughput, aumento de latência, e uso de CPU serão medidos. A capacidade de se adaptar às trocas rápidas entre redes heterogéneas será também avaliada. Os resultados do benchmark permitirão a minimização da degradação do serviço causada pelo uso de túneis VPN na rede em ambiente móvel da Veniam.

i ii Abstract

This dissertation was proposed by Veniam, a start-up working on vehicular networks. Offering connectivity to moving things over different technologies (DSRC, Wi-Fi, or 4G LTE) while main- taining a good quality of experience for users is a challenging endeavour. The use of VPNs facilitates network management, by logically placing clients inside the same local network. This can be used for simpliﬁed remote control, and to hide physical network changes (new access point, new IP address) from other services or applications. They can also provide security features, in the form of encryption and authentication. VPNs are commonly well-suited to solve the connectivity problem for stationary clients, equipped with reasonably high processing power. However, VPNs fail in mobile scenarios, break- ing end-to-end connections when clients switch between network access points. Moreover, advanced cryptography and protocol overhead means several VPN solutions demand high computational power at the client side. Applying these solutions to the fast-moving, performance constrained devices deployed in Veniam connected ﬂeets results in a severely degraded service. In this dissertation, different VPNs will be researched and compared, with the goal of select- ing a suitable solution for Veniam’s use case. For each implementation, throughput degradation, latency increase, and CPU usage will be measured. Their ability to adapt to rapid switching between heterogeneous networks will also be evaluated. The benchmark results will allow for the minimization of service degradation caused by the use of VPN tunnels in Veniam’s constrained mobile environment.

iii iv Acknowledgements

There are several people I would like to thank for their help in the making of this dissertation. Firstly, my supervisor Prof. Ana Aguiar, whose ideas, feedback and suggestions were fundamental to correctly tackle the problem I was given to solve. Also, as a lecturer, Prof. Ana Aguiar was a great contributor to the growth of my interest in the telecommunications and computer network fields and is someone any person would be lucky to have as a mentor. My gratitude also goes to my second supervisor, Eng. António Damião Rodrigues, whose support was invaluable, and without whom this dissertation would look much different and unpol- ished. I cannot thank him enough for the time spent reviewing my work, providing very detailed and clear feedback, and for always being available to answer my questions. I trust his input made this dissertation richer, and I am glad for all his help. I would also like to thank Eng. Diogo Lopes, my supervisor at Veniam, for his guidance and explanation of the Veniam network architecture. This has helped make sure the test scenarios were appropriate, and the results relevant to the Veniam use case. Of course, a big thank you to the incredible Veniam team for receiving me so well at their office. It was a pleasure to work alongside you and to witness such innovative ideas being born and developed in the heart of Porto. Finally, I am eternally grateful to my family, and specifically to my parents, Natércia Magal- hães and Rogério Francisco, for their belief in the importance of education and their unconditional support. I can always count on them, and for that, I am extremely lucky. I would also like to thank my friends, and specifically Jessica Rodrigues, for being such an important source of moral support, and for always having my best interests at heart.

João Francisco

v vi “Eles não sabem, nem sonham, que o sonho comanda a vida, que sempre que um homem sonha o mundo pula e avança como bola colorida entre as mãos de uma criança.”

António Gedeão

vii viii Contents

1 Introduction1 1.1 Context ...... 1 1.2 Motivation ...... 1 1.3 Objectives ...... 2 1.4 Dissertation Structure ...... 3

2 Problem Characterization5 2.1 Current State of Vehicular Networks ...... 5 2.2 Future Vision ...... 6 2.3 Problem Deﬁnition ...... 6

3 Literature Review9 3.1 Different VPN solutions ...... 9 3.2 Mobility in VPN connections ...... 10 3.3 Conclusions ...... 12

4 Methodology 13 4.1 Proposed Solution ...... 13 4.2 Experimental Set-up ...... 16 4.3 Network and Component Set-up ...... 16 4.3.1 Mobility Overhead ...... 17 4.3.2 Computational Overhead ...... 18 4.4 Testing procedure ...... 19 4.4.1 General Conﬁgurations ...... 19 4.4.2 Mobility Overhead ...... 21 4.4.3 Computational Overhead ...... 21

5 Results 23 5.1 Computational Overhead ...... 23 5.1.1 CPU Usage ...... 23 5.1.2 Throughput ...... 24 5.1.3 Latency ...... 25 5.2 Mobility Overhead ...... 26 5.2.1 Conclusions ...... 28

6 Conclusions and Future Work 29 6.1 Objective Satisfaction ...... 29 6.2 Future Work ...... 29

ix x CONTENTS

References 31 List of Figures

1.1 Initial VPN connection ...... 4 1.2 Endpoint address updating, ﬁxed VPN interface address ...... 4

4.1 Handshake procedure comparison ...... 15 4.2 Scheme of network and device set-up used for mobility overhead experiments. . . 18 4.3 Scheme of network and device set-up used for computational overhead experiments. 19

5.1 CPU usage comparison ...... 24 5.2 Throughput comparison ...... 25 5.3 Latency comparison ...... 26

xi xii LIST OF FIGURES List of Tables

3.1 Results of basic functionality from Berger [1]...... 10 3.2 Performance measurement results from Berger [1]...... 11

4.1 Comparison of OpenVPN and WireGuard ...... 14 4.2 Raspberry Pi key specifications ...... 17 4.3 Encryption and authentication algorithms used in each security configuration . . 20 4.4 OpenVPN security features ...... 21 4.5 Summary of endpoint configurations, according to security and test categories . . 22

5.1 Number of pings sent or received by a demoted interface in the different test scenarios ...... 27

6.1 Average penalty per metric compared to plain Ethernet (lower is better) . . . . . 30

xiii xiv LIST OF TABLES Abbreviations and Symbols

3DES Triple Data Encryption Standard ACK Acknowledgment AES Advanced Encryption Standard AP Access Point API Application Programming Interface Auth Authentication AWS Amazon Web Services Cert Certiﬁcate CPU Central Processing Unit DHCP Dynamic Host Conﬁguration Protocol DSRC Dedicated Short-range Communications EC2 Elastic Compute Cloud GB Gigabyte GCM Galois/Counter Mode GPLv2 GNU General Public License version 2 HIP Host Identity Protocol HMAC Hash-based Message Authentication Code IoT Internet of Things IP Internet Protocol IPSec Internet Protocol Security IPv4 Internet Protocol version 4 ISP Internet Service Provider L2TP Layer 2 Tunnelling Protocol LAN Local Area Network LTE Long Term Evolution NAT Network Address Translation Mbits/s Megabits per second MHz Megahertz MOBIKE IKEv2 Mobility and Multihoming Protocol ms milliseconds MTU Maximum Transmission Unit MUSeS Mobile User Secured Session P2P Peer-to-peer pp Percentage points PPTP Point-to-Point Tunneling Protocol RC4 Rivest Cipher 4 RPi Raspberry Pi RSU Roadside Unit

xv xvi ABBREVIATIONS AND SYMBOLS

RTT Round-trip Time SHA Secure Hash Algorithms SSTP Secure Socket Tunneling Protocol STCP Sociedade de Transportes Colectivos do Porto TCP Transmission Control Protocol TLS Transport Layer Security UDP User Datagram Protocol USB Universal Serial Bus V2V Vehicle-to-Vehicle V2I Vehicle-to-Infrastructure VLAN Virtual Local Area Network VoIP Voice over Internet Protocol VPN Virtual Private Network Chapter 1

Introduction

1.1 Context

VPN (Virtual Private Network) solutions are widely used for many purposes. Although initially developed to allow remote access to private networks from an external point - for example, to read work documents stored in the company’s local network while at home -, new uses have come up. More recently, the general public has found this technology helpful in encrypting and protecting their data, obfuscating their communications to hide them from trackers or mass surveillance agents. This use case has led to the appearance of many VPN providers, offering the service on a subscription basis, with a focus on its security aspects or end node locations, allowing access to geo-locked content. By establishing a VPN session with a VPN server, it is also possible to traverse NAT (Network Address Translation) devices. NAT is very widely used to prevent IPv4 address space exhaustion. For a certain network, only one public IP address is attributed to a network gateway, and all devices connecting to it receive a private IP address, not directly accessible from the outside. This causes issues when trying to access a machine placed behind a NAT. These ‘behind-NAT’ machines can become accessible on the virtual network that is created by a VPN. This can be achieved through NAT ‘hole-punching’. By sending some data to the server when establishing the tunnel, a connection is opened and a register of it is stored in the NAT. Then, as trafﬁc is received by the router on a certain port, as long as the register has not expired, it can be redirected to the correct client, allowing future inbound connections to succeed, since packets destined to the combination of IP and port are correctly routed and not discarded. Without the VPN, inbound trafﬁc would not be recognized as part of an existing connection and would be dropped, or it would be directed to the public IP and the NAT would not be able to translate it to the intended client.

1.2 Motivation

This dissertation was proposed by Veniam, a tech start-up working on the future of vehicular mesh networks - “The Internet of moving things”. In the city of Porto, its technology has been

1 2 Introduction implemented in the STCP public bus fleet, providing free Wi-Fi access to riders, and cloud services to the transportation company. Leveraging the power of a diversity of access networks, cost is kept low and coverage im- proved. Three technologies can be used to connect to the Internet: Wi-Fi, 4G LTE or DSRC (dedicated short-range communications). Vehicles can communicate over DSRC on a Vehicle- to-Vehicle (V2V), or Vehicle-to-Infrastructure (V2I) basis. Roadside units (RSU) are installed in heavy traffic areas, offloading some of the data and avoiding expensive 4G LTE. Vehicles can also connect to urban sensors, which use the Veniam network to upload their measurements. This op- portunistic connection allows the deployment of low cost, scalable Internet of Things (IoT) device networks. The mobile, multi-technology nature of this network poses some challenges not faced by tra- ditional networks. Access points change very quickly, so a seamless, low latency handover is necessary. These transitions should be invisible to the user, who must be able to maintain a stable connection to any web services they may be using. Using a VPN helps overcome some of the challenges. It can aid in crossing NAT and firewalls by keeping a connection open - for example, a TCP session, or by periodically sending packets over UDP to the VPN server. An access point switch can be quickly accounted for by updating the endpoint address of the VPN, while all traffic can continue to be sent to the local fixed IP address of the VPN interface. Web services would also be oblivious to these changes since, from their perspective, the device is static. Traffic sent inside the tunnel would continue to be routed through the virtual interface, which does not change address. An initial VPN connection is schematized in Figure 1.1, and a reconfiguration in Figure 1.2. Importantly, VPN is a straightforward way of adding security, namely authentication and encryption, protecting the data in transit.

1.3 Objectives

Veniam intends to implement a low overhead VPN solution on their vehicular networks. They have requested that different solutions are selected and compared, according to the following requirements:

• Low resource usage, namely CPU;

• Reduced throughput degradation;

• Low latency increase;

• Fast connection recovery after an AP switch.

Collectively, the increased CPU usage and latency, and reduced throughput, will generally be called the VPN’s ‘overhead’. Many VPN solutions are resource heavy, especially since cryptographic operations can be CPU intensive. The OBUs (onboard units) used by Veniam are not very powerful, and so these solutions result in signiﬁcant performance penalties. 1.4 Dissertation Structure 3

Therefore, the objective of this dissertation is the comparison of different VPN solutions, and the implementation on Veniam’s network of the one that more adequately fulﬁlls the needs of the company.

1.4 Dissertation Structure

Besides the introduction, this dissertation contains 6 more chapters. In chapter2, a general overview of Veniam’s goals and market position is laid out and the problem analysis is made. This is included in order to position the research carried out in this dissertation into the real world scenario of Veniam’s product offering, and to justify its relevance. In chapter3, a literature review is to be found, presenting relevant related work, that inﬂuenced decisions regarding the planning of this dissertation. In chapter4, a solution is proposed and a description of how the proposed tests were carried out is made. In chapter5, the results of the benchmark are presented. Finally, in chapter6, the conclusions are drawn and suggestions for future work are made. 4 Introduction

Figure 1.1: Initial VPN connection

Figure 1.2: Endpoint address updating, ﬁxed VPN interface address Chapter 2

Problem Characterization

2.1 Current State of Vehicular Networks

The automotive industry has traditionally been slow to keep up with technological advancements. While manufacturers have invested heavily in increasing efficiency, reducing pollutant emissions and making vehicles safer, a big rethink of mobility and how vehicles behave together has just recently started happening. Strict regulation, long release cycles and interoperability between brands and models have been important barriers to the adoption of disruptive technology. Congested cities started studying and implementing measures to improve mobility and pre- serve the environment. Incentives to use public transportation, improvements or extensions to bus, rail or metro networks are valuable and effective efforts carried out by local and central gov- ernments around the world. Some cities have resorted to making some downtown areas car-free, or imposing limitations or taxes to circulation in certain areas. Examples of this are London’s ‘Congestion Charge’ [2] or Delhi’s ‘Odd-Even’ rule [3]. More advanced technology has already been developed and implemented as well, on the way to full smart mobility. Traffic lights can be supported by sensors that detect the presence of cars, avoiding a green light on an empty road causing traffic build-up on an adjacent, more congested road. Traffic cameras can be used to analyze patterns and support decisions to change road signs, improve roads, create or re-route bus routes, or other measures. Vehicles have, however, remained largely mechanical machines, with limited computing capa- bilities or automation. More recently, entertainment, navigation, safety and assistant features have been added, requiring some computing - for example, maps, assisted parking, rear-view cameras. For any vehicle’s features to be considered truly smart, though, communication is necessary. That would allow adaptation to current conditions, recommendations based on location and context, collaborative safety, with one vehicle warning others in the vicinity of a hazard, simplified fleet management, over the air software updates and, eventually, completely automated driving. The options currently available are limited and costly. Since vehicles are inherently mobile, current Internet infrastructure is not suitable. Wi-Fi has a very limited range, so relying solely on

5 6 Problem Characterization this technology would result in frequent service unavailability. Mobile data, such as 4G LTE, provides fairly good coverage, but is very expensive, and congestion or high latency make it unreliable for use with real-time safety applications.

2.2 Future Vision

Veniam sees the potential in connected, smart fleets, and has set out to find a solution to the connectivity problem. They have determined no single technology is enough to provide suitable reliability and user experience. Connected cars are expected to generate huge data volumes, with autonomous vehicles demanding up to 40 terabytes of data for every eight hours on the road [4]. Therefore, a combination of technologies should be used. With different characteristics, like coverage, cost, or throughput, they can be combined to maximize quality of service and mini- mize cost. Veniam’s product manages Wi-Fi, DSRC, and 4G LTE, ensuring smooth and quick handovers. Vehicles can communicate directly with the infrastructure (single-hop) or as a mesh (multi-hop). This increases capacity, allows for cost management, or prioritization by data type and delay tolerance. Low latency technologies, such as DSRC, may be used for time sensitive information, while mobile data can be used for entertainment, if desired. In this manner, Veniam’s product and platform aims to unlock the potential for innovation provided by reliable, high performance connectivity, powering future smart cars and autonomous fleets.

2.3 Problem Deﬁnition

In the city of Porto, Veniam connected vehicles communicate with the Internet via three interfaces:

• 4G LTE (Vodafone network);

• DSRC (V2V and V2I);

• Wi-Fi (Porto Digital access points).

Along its journey, a vehicle switches access points very frequently, with a connection some- times lasting only a few seconds. A handover must occur smoothly and all established sessions kept. If this fails, users face a poor experience, since their Internet requests would often be left with a lost answer. With no mobility mechanisms, a VoIP call, for example, would be dropped at every access point switch. For the proposed challenge, a VPN solution adapted to low resource machines is to be selected, with low connection reestablishment times, limited throughput and latency degradation, that can be universally deployed in IP networks, without the need of additional configurations to assure protocol compatibility with any networking devices. Currently, a strong business relationship between Veniam and its Internet service providers (ISPs) - Porto city hall and Vodafone -, allowed the provision of fixed, public IP addresses. This factor, together with the use of IP-in-IP mobility tunnels, allows the desired seamlessness to be 2.3 Problem Definition 7 achieved. However, this solution is not scalable - it requires special agreements with ISPs and limits the choice of service providers, which can be particularly critical in the event of international expansion. A more flexible approach would, for example, allow any open Wi-Fi hotspot to serve as Internet provider, regardless of its origin. 8 Problem Characterization Chapter 3

Literature Review

3.1 Different VPN solutions

There are many VPN solutions available on the market. They differ on the basis of performance, ease of configuration, security, processing power requirements, memory or bandwidth usage, device and operating system compatibility, layer on which they operate, source code availability, and other factors. The most commonly referred technologies in literature are IPSec, PPTP, L2TP, SSTP, and TLS (Transport Layer Security) based solutions, like OpenVPN. SSTP can cross firewalls that may block IPSec or PPTP traffic, and shows good throughput and jitter results, as well as low packet loss over wired and wireless connections, surpassing IPSec [5]. The PPTP protocol is considered insecure and its use is discouraged. L2TP is usually combined with IPSec to provide authenticity and data privacy, increasing its overhead. If not combined with IPSec, it does not natively offer these features. The use of VPN tunnels has a significant impact on throughput, response time and CPU usage, due to the required additional processing. The packet size increase can also lead to packet fragmentation, if the MTU (maximum transmission unit) value is exceeded, possibly causing failures in packet integrity tests [1]. A practical analysis of some VPN solutions is also carried out by Berger [1]. The obtained results are fairly old by now. Therefore, no strict conclusions should be taken from them any- more. Regardless, they may be useful as a reference. A table comparing the basic functionality of different solutions is presented in Table 3.1, and comparing the performance in Table 3.2. In a comparison between IPSec, PPTP and L2TP, IPSec based solutions have the lowest connection initialization times - 0,72 to 1,96 seconds -, whereas L2TP and PPTP take 7,42 and 7,84 seconds, respectively. Round-trip times (RTT) suffer big increases with any VPN solution. Compared to 0,18 milliseconds with no VPN, the solution that comes closest is PPTP, at 4,15 milliseconds. L2TP sits at 10,56 milliseconds, and IPSec based solutions vary from 14,76 to 22,01 milliseconds. The author attributes this to the different protocol overheads, dependent on the type of tunnel, and varying encryption complexities of the protocols. Tunnel re-initialization times, after a 10 second disconnection, range from 31 to 100 seconds for the IPSec based solutions. L2TP and PPTP failed

9 10 Literature Review

Table 3.1: Results of basic functionality from Berger [1]

Init RTT Re-init VPN Technology Vendor time [sec] [msec] time [sec] No VPN (ethernet) - 0,18 - IPSec Cisco 0,72 18,00 33 Netscreen 0,72 15,86 31 Symantec 1,89 14,76 100 Watchguard 1,96 22,01 33 L2TP Microsoft 7,42 10,56 - PPTP Microsoft 7,84 4,15 - to reconnect automatically. Throughput also suffered a dramatic reduction, from 94 Mbits/s without a VPN, to 29,80 Mbits/s over PPTP, 8,72 Mbits/s over L2TP, and varying between 1,45 and 7,02 Mbits/s for IPSec based solutions. Again, differences are mostly due to different encryption algorithms (RC4 for PPTP and 3DES for IPSec and L2TP tunnels). A comparison between IPSec and OpenVPN, a TLS based VPN technology, made by Kotuliak, Rybár and Trúchly [6], shows moderately better performance is achieved with IPSec, regarding throughput and response time. However, it is complex to configure, since it attempts to support many different situations with excessive configuration options, and requires access to the network interface, being a lower level solution, closer to the kernel. Meanwhile, OpenVPN is simpler and requires less privileges, since it operates at the user level. Both solutions have a big impact on connection throughput and response time, when compared with plain Ethernet. IPSec does not natively provide support for NAT devices [7]. For a low overhead implementation, UDP tunnels are recommended instead of TCP. With this configuration, retransmission problems, TCP meltdown and double retransmission due to the sending of TCP traffic inside a TCP tunnel should be avoided, and latency reduced. The choice of UDP tunnels uses the connection more efficiently, improving transfer times and speeds [8]. Additionally, Zhou and Luo [9] suggest NAT and firewall traversal methods using UDP. The encryption algorithm used has a very significant impact on relevant metrics, such as throughput and round-trip time. Simpler algorithms tend to result in lower performance penalties, but often at the cost of proper security, since some of them may be vulnerable, outdated and being phased-out. The use of the 3DES cipher is discouraged, as it presents performance and security issues. AES or Blowfish are preferred over it [6].

3.2 Mobility in VPN connections

Most common VPN solutions are not adapted to mobile users. Access point and, consequently, IP address and route changes, are not handled gracefully, leading to dropped VPN connections or long reestablishment times. Since Veniam’s connected vehicles constantly switch access points, prior research on how different solutions handle mobility was consulted. 3.2 Mobility in VPN connections 11

Table 3.2: Performance measurement results from Berger [1]

Throughput Throughput VPN Technology Vendor 1 TCP session 100 TCP sessions [Mbits/s] [Mbits/s] No VPN (ethernet) 94,0 92,2 IPSec Cisco 2,71 - Netscreen 7,02 - Symantec 3,25 - Watchguard 1,45 - L2TP Microsoft 8,72 6,42 PPTP Microsoft 29,80 8,25

Zúquete and Frade [7] suggest modifications to OpenVPN to achieve a reduction in tunnel reconfiguration time. The possibility of a Mobile IP based approach is referred, but its weak adoption and challenges related to NAT devices make it unappealing. According to Zúquete and Frade [7], an IP change forces a new tunnel negotiation when using the unaltered OpenVPN. Two proposals were made to improve the tunnel reconfiguration process - lazy reconfiguration and aggressive reconfiguration. The lazy method can lead to a bigger data loss than the other method (due to the possibility of some server to client packet loss after the switch), limitations regarding encryption cipher choices or increased overhead because of the inclusion of identifiers in the packets. The aggressive method depends on the capacity of the client to detect changes to its own IP address in the TUN interface, which requires some extra processing due to the need of continuous probing. It also floods the network with reconfiguration message pings when this change occurs, sending them continuously until a confirmation of tunnel reestablishment success is received. Both the presented solutions achieve drastically lower tunnel reconfiguration times when compared with standard OpenVPN. The unaltered solution’s time of 2,2 seconds was reduced to between 4 and 39 milliseconds. The choice of TCP tunnels (such as those used by PPTP or SSTP) is not favourable to mobility, since the TCP connection would have to be adapted to the client’s new address. Since TCP is a connection oriented protocol, an address change would either break this connection, or require it to be adapted, so as to inform of the new address. On the other hand, UDP is connectionless, so packets are independent from one another. UDP packets would just have to start being sent to a new endpoint, whereas a TCP session would have to be modified. Alshalan, Pisharody, and Huang [10] propose techniques to make application sessions more resilient to long periods of network unavailability, as is frequently the case in mobile environments. By storing unacknowl- edged packets in cache and suspending applications, data loss is prevented and TCP sessions are maintained, avoiding their throughput degrading slow-start. This way, connections remain active regardless of network switches or unavailabilities. Although relevant to the problem at hand, it would be more favourable to reconfigure VPN tunnels quickly enough to avoid application’s sessions dropping than to implement a similar solution to the one proposed. Firstly, because the use of caches and other additional network equipment increases network complexity, cost, and adds 12 Literature Review new failure points. Secondly, long network unavailability handling is not what is being optimized, but rather extremely short unavailabilities when the access point changes. Ahmat, Barka, and Magoni [11] present and compare four mobility-focused solutions - N2N, HIP, MOBIKE and MUSeS. N2N is a decentralized P2P VPN, capable of crossing NAT and firewalls. MOBIKE is an IPSec based solution, which it combines with Mobile IP, and consequently presents the previously referred disadvantages of these two technologies. HIP (Host Identity Pro- tocol) introduces a new namespace, the Host Identity, filling a gap between the IP and DNS names- paces. The Host Identifier, a public key of an asymmetric key-pair, identifies a single host, and can be used for identification instead of IP addresses, which are only used for packet forwarding. It can be combined with IPSec for traffic payload protection [12]. The introduction of the new HIP layer, between the transport and IP layers, requires the modification of the operating system. MUSeS is a P2P based solution developed by the paper’s authors. The proposed solutions show very large connection reestablishment times, between 12 and 51 seconds, except for MUSeS, which takes 3 seconds. However, for the problem at hand, even lower times are required for Seamless Network Roaming, defined by Alshalan, Pisharody, and Huang [13] as the conservation of the VPN functionality without user action, in cases of vertical handoff (when the access point switch results in a medium switch - for example, from 4G LTE to DSRC) and horizontal handoff (access points change but communication occurs through the same medium - for example, switching DSRC access points), which cause the client’s IP address to change.

3.3 Conclusions

According to the problem’s requirements, a lightweight and mobility ready UDP VPN solution would meet the ﬂexibility and compatibility needs. Performance losses must be measured and mitigated to make the solution viable. Chapter 4

Methodology

4.1 Proposed Solution

To find the most suitable solution to this problem, different VPN solutions are to be compared - the well-established TLS based OpenVPN, and a new lightweight solution, the kernel level Wire- Guard. With these VPN tunnels, the path from client to exit node (VPN server) is irrelevant, since from an outsider’s perspective, the client appears static. Therefore, any access point could be used flexibly and, with an appropriate VPN configuration, safely. However, this approach can result in a poor outcome if not properly adapted and tested. VPN solutions have traditionally been developed with different use cases in mind. A worker sitting at home, wanting to access corporate documents from a powerful computer, and a connected vehicle traveling at tens of kilometers per hour on urban streets are very different scenarios. Connection establishment time and processing power requirements are very critical in the second case, and often left unoptimized in existing solutions, because those metrics are not as relevant in the first case. In this dissertation, comparative tests will be carried out for different VPN solutions and, based on those results, the most appropriate one will be chosen and configured to suit Veniam’s use case. A brief summary of the features of the solutions chosen for comparison, OpenVPN and Wireguard, is provided in Table 4.1. If OpenVPN is configured to operate over UDP, the TLS handshake is carried out over a reliable transport layer on top of UDP, requiring acknowledgment packets. A diagram of the Open- VPN handshake packet exchange is presented in Figure 4.1a. Note that ACK messages may be prepended to TLS control messages, so packet captures may show fewer dedicated ACK records. Data messages after the handshake, however, are tunnelled over plain, unreliable, UDP. OpenVPN emulates a network device by use of a TUN/TAP virtual network driver. Packets sent by the network stack to the TUN/TAP virtual network are received directly on the user-space by the Open- VPN application. Being a user-space application, packets received by or sent to the OpenVPN interface need to be copied to/from the user-space, where they are processed (encrypted/decrypted,

13 14 Methodology

Table 4.1: Comparison of OpenVPN and WireGuard

OpenVPN WireGuard Layer User-space Kernel/Layer 3-only Compatibility Multi-Platform Linux Handshake TLS Single round trip key exchange Authentication Keys Certiﬁcates Pre-shared static key Protocol UDP or TCP UDP Encryption OpenSSL cipher suite ChaCha20Poly1305 Development State Stable Experimental License Open source (GPLv2) Open Source (GPLv2) encapsulated/decapsulated, accepted or discarded), and then sent again to the interface. These context changes (network interface controller, to kernel-space, to user-space, and then back) increase processing delays and may result in performance degradation. WireGuard is implemented as a kernel module, so it operates on the packets directly at kernel level, integrating with the standard Linux kernel APIs. Conﬁguration of the tunnel is done using the Netlink kernel interface, by means of a user-space tool. The handshake is also simpler, com- prising two messages - initiator to responder, and responder to initiator - containing the negotiated session keys. A diagram of this handshake is presented in Figure 4.1b. 4.1 Proposed Solution 15

(b) WireGuard handshake

(a) OpenVPN handshake

Figure 4.1: Handshake procedure comparison 16 Methodology

4.2 Experimental Set-up

To benchmark the VPN solutions, two test categories were deﬁned: computational overhead and mobility overhead.

Computational overhead: The purpose of this category is to measure the computational overhead imposed by different VPN solutions. More speciﬁcally, an evaluation of how low resource devices - e.g., Veniam’s OBUs - are affected by being included in a VPN and running VPN software, as opposed to communicating without tunnels, is made. To quantify this, the following metrics were measured:

• Throughput;

• Latency of the connection between client and server;

• CPU usage.

It is expected that the use of such devices in a VPN will slightly increase latency, and that once the CPU usage saturates - that is, once the computing capacity is exhausted by the encryption and encapsulation of packets - throughput stagnates.

Mobility overhead: Here, the behaviour of the client under mobility is analyzed. In this set of experiments, a client communicating with a VPN server will roam between different access points, connected to separate access networks. The goal is to evaluate how the VPN solutions handle this change of context, speciﬁcally, whether:

• The tunnel connection is broken;

• Packets are lost;

• Additional time is needed for the VPN to adapt and reconﬁgure.

The tests do not intend to account for the inﬂuence of other sources of overhead during access network roaming: e.g., Wi-Fi authentication and association times. It is expected that WireGuard will handle mobility seamlessly, since it is presented as having ‘built-in roaming’. OpenVPN, however, may present some issues and delays, as previously discussed in the literature review.

4.3 Network and Component Set-up

Figures 4.2 and 4.3 depict the network and component set-up used for the mobility and computational overhead test categories, respectively. In order to correctly test and compare the behaviour and performance of the two VPN solutions, an Ubiquiti ERPro-8 router, two Raspberry Pi 2 model B running Raspbian Stretch (see key speciﬁcations in Table 4.2), a TP-Link TL-WR841N Wi-Fi access point, a TP-Link TL-WN725N 4.3 Network and Component Set-up 17

Table 4.2: Raspberry Pi key speciﬁcations

Speciﬁcations Model Raspberry Pi 2 Model B CPU 900MHz quad-core ARM Cortex-A7 RAM 1 GB 1x 100 Base Ethernet Interfaces 4x USB

Wi-Fi USB dongle, a Huawei E3276s-150 4G LTE USB dongle, and an AWS Cloud instance of type ‘t2.micro’ running Ubuntu 18.04 were used. The two Raspberry Pi and the AWS instance had OpenVPN version 2.4.6 and WireGuard version 0.0.20180531 installed. In the next subsections, the reasoning behind the network set-up choice is described, in the context of each test category: (1) mobility overhead; and (2) computational overhead.

4.3.1 Mobility Overhead

To evaluate VPN overhead under endpoint mobility, the experimental set-up must fulﬁll the following requirements:

• During each experiment, two peers must establish a VPN session between each other.

• One of the peers must be mobile - i.e. it must switch between different access networks - while communicating with the other peer, which must be ﬁxed.

• The network paths used by the mobile VPN peer to reach the ﬁxed peer should differ between switches of access network. This means packets should travel through different routes, with new endpoint IP addresses, using the nomenclature of Figures 1.1 and 1.2.

Access network switches: To mimic access network roaming, two separate Internet connections were used:

1. The Internet connection used by the Veniam office (where the experiments were conducted), provided by the Wi-Fi access point, which was connected through the ERPro-8 router to the office network via an Ethernet socket in the office. All devices connected to the ERPro-8 router were additionally configured to use separate VLANs, and different Ethernet ports on the router had different DHCP servers configured.

2. A 4G LTE mobile connection, conﬁgured with a public IP address, provided by the USB dongle.

Wi-Fi and 4G LTE connections, instead of, for example, Ethernet, were selected because they are both wireless access mediums, similar to the ones used by the connected vehicles. 18 Methodology

Figure 4.2: Scheme of network and device set-up used for mobility overhead experiments.

Location of fixed VPN peer: To completely separate the mobile and fixed VPN peers, the fixed VPN peer was deployed in an Ubuntu Linux instance on AWS EC2, in Frankfurt, Germany. This instance was used instead of the ‘Pi Server’. This was done to ensure that the VPN connections established over each of the access networks were made over the public Internet, and did not experience significantly different conditions on each of the access networks used, e.g., RTTs between peers.

4.3.2 Computational Overhead

For the computational overhead case, the goal was to determine the effect of including constrained devices as peers in a VPN tunnel, and not take into account Internet connection speed or quality. As such, a local conﬁguration was preferred, unlike in the mobility experiments. The tests were performed between the Raspberry Pis, over Ethernet on the local network managed by the ERPro-8 router. This way, the connection is stable and predictable, ensuring throughput or latency ﬂuctuations are caused by the VPN solution being used, and not by current network conditions, such as congestion. 4.4 Testing procedure 19

Figure 4.3: Scheme of network and device set-up used for computational overhead experiments.

4.4 Testing procedure

General methodology aspects, which apply to both test categories - computational overhead and mobility overhead - are described ﬁrst. The speciﬁc methodologies followed to conduct the experiments for each case are then described. The scripts used for automating the tests described below can be found on my GitHub page at https://github.com/jfrancisco0/VPN_benchmarking.

4.4.1 General Conﬁgurations

4.4.1.1 Security Conﬁgurations

For the computational overhead test category, multiple security configurations were considered, as summarized in Table 4.3. The reasoning behind the different security configurations is to account for the influence of security features on the performance of the VPN solutions. For example, a considerable part of the overhead is expected to be due to encryption and authentication. Also, such differentiation is useful to the company: the company may prefer to manage security in a different way, and consider full traffic encryption as excessive for their activity. The benefits of 20 Methodology

Table 4.3: Encryption and authentication algorithms used in each security conﬁguration

Conﬁguration Packet Encryption Packet Authentication Full OpenVPN AES-256-GCM HMAC SHA1 Auth-only OpenVPN None HMAC SHA1 Insecure OpenVPN None None WireGuard ChaCha20 Poly1305 a cautious approach to security should, however, be stressed, and deploying a VPN solution in a production environment with these features turned off may be short-sighted. Below, the choices of conﬁgurations are described in more detail, for each of the considered VPN solutions:

OpenVPN: OpenVPN offers a long list of ciphers, using the OpenSSL security suite. OpenVPN was configured to use AES-256-GCM as cipher, initialized with a 256 bit key, and certificates were generated using the Easy-RSA tool. AES-256-GCM was chosen because it was the recommended default as of version 2.4.X of OpenVPN, providing a good balance of performance and security, without any known vulnerabilities. AES is a block cipher, and cryptographic operations are very fast if dedicated hardware is present (i.e., if the processor has AES acceleration). The Raspberry Pi used does not have this feature. Table 4.4 provides a breakdown of OpenVPN security features. The authentication-only configuration of OpenVPN has authentication features turned off, and the insecure configuration has all security features turned off. The secure configuration has all features enabled.

WireGuard: WireGuard is cryptographically opinionated and intentionally lacks cipher and protocol agility [14]. This means the algorithms are not easily changed, and security features cannot be disabled. WireGuard uses ChaCha20Poly1305 for authenticated-encryption. ChaCha20 is a stream cipher, which should result in good performance in software-only mode (with no hardware acceleration). OpenVPN does not offer ChaCha20 as a cipher option, so the comparison will be made using AES-256-GCM on OpenVPN and ChaCha20Poly1305 on WireGuard.

4.4.1.2 Endpoint Conﬁgurations

For both sets of experiments, all tests involve exactly two peers. The client (or first peer1) is always the device named ‘Pi Client’ in Figures 4.3 and 4.2, and the server (or second peer) is either the ‘Pi Server’ or an AWS EC2 instance, depending on the test. Table 4.5 summarizes the different endpoint configurations, according to the type and location of the server (or second peer), as well as the security configurations mentioned in section 4.4.1.1.

1WireGuard does not differentiate clients or servers 4.4 Testing procedure 21

Table 4.4: OpenVPN security features

OpenVPN Key Exchange Encryption Authentication Difﬁe-Hellman X Server Cert Veriﬁcation X HMAC Firewall X Cryptographic Cipher X Packet Authentication X

4.4.2 Mobility Overhead

Procedure: In a real-world scenario, an access point switch would occur naturally with the movement of a VPN peer (e.g., a vehicle), as an access point would go out of range as a new one would come within range. In the ofﬁce, the test devices were stationary. To mimic a real-world scenario in the lab, the below procedure was followed:

1. The ‘Pi client’ had routes available to two interface types: (A) Wi-Fi (via the Wi-Fi access point); and (B) 4G LTE (via the 4G USB dongle).

2. When a switch from interfaces A to B is to occur (e.g., say A is the Wi-Fi interface, B the 4G LTE interface), the default route is updated to choose interface B with metric value ‘1’, making it the one with highest priority. This way, trafﬁc immediately starts being routed to the desired interface, effectively changing the access network.

3. During steps 1 and 2, pings are continuously sent by the ‘Pi client’ to the VPN peer deployed in the AWS EC2 instance, at a cadence of 5 milliseconds. This should provide enough resolution to notice increased delays or packet losses due to the switching.

Measurement output: Tunnel timeouts, packet losses or an increased delay are possible conse- quences after a switch. Logs and packet captures will enable conclusions to be taken.

4.4.3 Computational Overhead

Throughput was measured using the ‘iPerf3’ tool. It was chosen because it is widely used aca- demically, easily configured, and provides the required results. An iPerf3 server was set up on the Pi server. A client was set up on the Pi client. The Pi server’s local Ethernet interface IP was used to test the throughput without VPN, and the WireGuard and OpenVPN virtual interface IP addresses were used to test the throughput with WireGuard and OpenVPN, respectively. The tests were run over TCP for one minute, obtaining sixty measurements (one per second). TCP was chosen because it finds the maximum throughput via the typical TCP flow control, while in UDP the bandwidth is configured manually, on iPerf3. Setting the bandwidth too low over UDP would not show the connection capacity, setting it too high results in packet loss. Since the goal is to find the maximum throughput, the TCP method is preferred. 22 Methodology

Table 4.5: Summary of endpoint conﬁgurations, according to security and test categories

Security Conﬁguration Mobility overhead Computational overhead Full OpenVPN VPN Server on AWS VPN Server on RPi Auth-only OpenVPN Not tested VPN Server on RPi Insecure OpenVPN Not tested VPN Server on RPi WireGuard VPN Server on AWS VPN Server on RPi

Latency was measured with the standard ‘ping’ tool included in Linux distributions. Twenty pings were sent by the Pi client to the Pi server, at a cadence of one per second, using the same methodology as with the throughput - that is, choosing the IP address based on the solution to be tested. CPU usage was measured during the iPerf3 tests, using the Linux tool ‘top’. It shows the currently running processes and CPU usage. To determine total CPU usage, the logs were captured and filtered to only include the value for ‘idle’, which represents the percentage of time spent in the kernel idle handler, over the desired time frame. Then, the total CPU usage is calculated as 100-‘idle’. To determine the contribution of the security features in service degradation, these tests were repeated for the different configurations of OpenVPN listed in Table 4.3. The logs and performance test results will provide data to quantifiably measure the impact of the VPN solutions on the performance of the connection. Chapter 5

Results

5.1 Computational Overhead

5.1.1 CPU Usage

CPU usage was measured at the Pi client, while exchanging trafﬁc between the two peers. CPU usage is then compared when using OpenVPN and WireGuard as VPN solutions.

OpenVPN vs. WireGuard: Figure 5.1a shows the distribution of CPU usage measurements collected at the Pi client using the Linux program ‘top’, during an iPerf3 TCP session with a duration of 60 seconds (1 minute). Figure 5.1a shows the results for three different cases: (1) no VPN usage; (2) OpenVPN with the ‘full’ conﬁguration (as shown in Table 4.3); and (3) Wireguard. The average CPU usage over plain Ethernet (i.e., without the establishment of VPN tunnels) is 7,4%, with OpenVPN 22,2%, and with WireGuard 34,0%. WireGuard uses more CPU than OpenVPN, even though the throughput over an OpenVPN tunnel saturates at a lower level than WireGuard. This occurs because OpenVPN is a single-threaded application, using only one core of the CPU at a turn for processing, which can be conﬁrmed with the ‘top’ tool. Since the Raspberry Pi’s processor contains four cores, saturation occurs at around 25% of usage. WireGuard offers multicore cryptography [15], allowing it to use more CPU capacity in multicore environments, resulting in faster encryption/decryption and higher throughput, if capacity is available.

Different security configurations with OpenVPN: Figure 5.1b compares CPU usage under the same conditions as above, but accounting for the effect of the different security configurations of OpenVPN (as specified in Table 4.3). The impact of encryption and authentication is clear. Average CPU usage with full OpenVPN is 22,2%, with authentication-only OpenVPN 19,7%, and with insecure OpenVPN 18,9%.

23 24 Results

(a) Comparison between plain Ethernet, full (b) Comparison between different OpenVPN OpenVPN, and WireGuard conﬁgurations

Figure 5.1: CPU usage comparison

5.1.2 Throughput

OpenVPN vs. WireGuard: Figure 5.2a shows throughput measurements collected during 60 second iPerf3 TCP sessions, using three different configurations: (1) no VPN usage; (2) OpenVPN with the ‘full’ configuration; and (3) Wireguard. Client side iPerf3 results for WireGuard showed a couple of outlier values, over the theoretical speed of 100 Mbit/s offered by the fast Ethernet link. These values (102 and 104 Mbit/s) are the first two measurements of the WireGuard iPerf3 test. This behaviour is recurrent, as confirmed with subsequent measurements: iPerf3 results for WireGuard commonly show these excessive values for the first two measurements. Client and server side results showed slight differences, and server side results did not contain outlier values above the link limit for WireGuard or any of the other scenarios. Server side results were deemed more reliable and precise, since those measurements take into account the influences of multiple networking stack layers on both client and server side, as well as the influence of the network. On the other hand, iPerf3 client side results are estimated at the application level. For these reasons, the results presented here are taken from the server iPerf3 logs. OpenVPN is at a clear disadvantage, when compared to WireGuard. Average throughput over plain Ethernet is 93,9 Mbit/s (thus close to the theoretical 100 Mbit/s offered by the fast Ethernet link), WireGuard reports 89,8 Mbit/s, a value much higher than OpenVPN, which reports 28,9 Mbit/s.

Different security configurations with OpenVPN: Figure 5.2b compares the throughputs achieved with the different security configurations of OpenVPN. A correlation between enabled security features and throughput is visible, with the insecure configuration of OpenVPN achieving the highest values. Average throughput with full OpenVPN is 28,9 Mbit/s, with authentication-only OpenVPN 41,5 Mbit/s, and with the insecure configuration 54,3 Mbit/s. 5.1 Computational Overhead 25

(a) Comparison between plain Ethernet, full (b) Comparison between different OpenVPN OpenVPN, and WireGuard conﬁgurations

Figure 5.2: Throughput comparison

5.1.3 Latency

OpenVPN vs. WireGuard: The impact of VPN solutions on latency was measured by sending 20 pings to the VPN server, again considering three cases: (1) no VPN tunnels; (2) OpenVPN with the ‘full’ configuration; and (3) Wireguard. Figure 5.3c shows the distribution of latency measurements for each of the three cases. One outlier, with a considerably greater value of 17,5 ms, is visible in the WireGuard results. This is the first ping message, and also the first message sent over the tunnel interface after Wire- Guard was configured. The WireGuard protocol considers silence a virtue [14], and no messages are exchanged when not needed. Therefore, while the tunnel was set-up before the ping message was sent, no connection was established with the Pi server peer. Once the first ping arrives at the interface, WireGuard executes the handshake, a one round-trip time key exchange, as described in Figure 4.1b. This results in an additional delay to send the first packet, as confirmed by this outlier value, since there is a need to wait for the handshake to take place. To better compare latencies, a separate plot with the first WireGuard ping omitted is given in Figure 5.3a. Average latency is 0,901 ms over plain Ethernet, 1,949 ms with full OpenVPN, and 2,406 ms with WireGuard. If the first WireGuard ping packet is not accounted for, the average latency with WireGuard is 1,60 ms.

Different security conﬁgurations with OpenVPN: Figure 5.3b compares latency results obtained with the different OpenVPN conﬁgurations. Average latency is 1,949 ms with full Open- VPN, 1,822 ms with authentication-only OpenVPN, and 1,777 ms with insecure OpenVPN. 26 Results

(a) Comparison between plain Ethernet, full (b) Comparison between different OpenVPN OpenVPN, and WireGuard, with ﬁrst Wire- conﬁgurations Guard ping omitted

Figure 5.3: Latency comparison

5.2 Mobility Overhead

Both OpenVPN and WireGuard handled mobility with no connection breakage. According to the literature (Zúquete and Frade [7]), OpenVPN was expected to timeout and cause a connection breakage. This was not the case in initial tests with a recent version of OpenVPN (v. 2.4.6).

Mobility experiments with OpenVPN version 2.4.6 and WireGuard: Ping messages are sent with a cadence of 5 milliseconds from the Pi client to the AWS server. After an access point switch, the change of IP address - from the address of the Veniam office connection, provided by the Wi-Fi access point to the Pi client, to the address of the Vodafone mobile connection provided by the 4G LTE USB dongle, and then again back to the office address -, is visible in the packet captures when sending traffic outside the VPN, over the OpenVPN interface, and over the WireGuard interface. After the switches, the tunnels remain connected, and no packet loss is reported by the ping tool. However, analysis of the packet captures on the client side show ping replies are still received 5.2 Mobility Overhead 27

Table 5.1: Number of pings sent or received by a demoted interface in the different test scenarios

Number of pings Number of pings Interface Solution sent by received by Switch demoted interface demoted interface Wi-Fi ->LTE 0 4 No VPN LTE ->Wi-Fi 0 4 Wi-Fi ->LTE 0 6 OpenVPN LTE ->Wi-Fi 0 6 Wi-Fi ->LTE 0 5 WireGuard LTE ->Wi-Fi 0 6 by the demoted1 interface for a short time (around 40 to 50 milliseconds - which corresponds to roughly one round-trip time) after a switch. Since the switch is accomplished via route manipu- lation, and all interfaces remain connected throughout the test, some packet loss (around 4 to 6 packets - see Table 5.1) that may occur in a real-world scenario is being masqueraded by this test methodology. Packet captures from the server side show that once a packet from the client arrives with a new IP address as source, all subsequent packets are received/sent from/to the updated address. This behaviour is natural, since the VPN server is serving replies to requests that contain an outdated source address. This occurs without a VPN, and also with OpenVPN or WireGuard, so it cannot be considered a mobility overhead caused by the VPN solution. Once packets start to arrive with the new endpoint address, the IP address is correctly updated and replies are delivered to the originating interface. Table 5.1 shows the number of pings sent and received by a demoted interface. As expected, pings were not sent over the demoted interface after the switch, but some - 4 to 6 - were still received. The ping values are considerably different depending on the access point, since 4G LTE, as a cellular technology, usually presents higher latency than a ﬁxed access. This is a technological limitation, and not an effect of the rapid switching being tested.

Mobility experiments with OpenVPN version 2.0.9: To confirm the behaviour reported by Zúquete and Frade [7], mobility tests were performed with OpenVPN version 2.0.9, as used by the authors. When using that version of OpenVPN, a change of access point does indeed result in a tunnel renegotiation. Additionally, it is longer than expected, taking around 6 minutes to recover after a route switch. Since OpenVPN is configured to send a keep-alive every 120 seconds, reconfiguration ought to be faster. With version 2.0.9 of OpenVPN, the following behaviour was observed:

At 0 minutes at the client instance Route switch

1For a switch from interface A to interface B, the route to interface B is set as preferred (low metric), demoting the route to interface A. 28 Results

Log at the server after 4 minutes Inactivity timeout in server (—ping-restart) Thu May 17 11:18:31 2018 client1/77.54.3.43:48814 SIGUSR1[soft,ping-restart] received, client-instance restarting Log at the client after 6 minutes Inactivity timeout in client Reusing SSL/TLS context Preserving previous TUN/TAP instance: tun0 (...) Connection is re-established

5.2.1 Conclusions

It can be concluded that mobility handling might have proved problematic in the past, but has been correctly incorporated into recent products. Both OpenVPN and WireGuard can be implemented in vehicular networks with no mobility overhead. It is recommended that keep-alive messages are sent frequently if it is desirable to maintain the clients reachable. While the VPN servers adapt to the change of IP address immediately, until the server is informed of the IP address change, communication is impossible. Of course, this is true regardless of the use of VPN solutions, as server to client communications would fail even without a VPN if the registered address no longer routes to the client. OpenVPN and WireGuard can be easily conﬁgured to send keep-alive messages, setting an upper limit to the time the client may be unreachable. Chapter 6

Conclusions and Future Work

6.1 Objective Satisfaction

The solution benchmarking tests were successful and provided useful results, a summary of which can be found in Table 6.1, where the penalties introduced by the use of each solution and conﬁgu- ration are presented. WireGuard appears to be well-suited to Veniam’s use case, showing impressive performance on low resource devices. Throughput is minimally affected and, while latency increases considerably compared to plain Ethernet, it still provides the best result of any of the scenarios tested. It does, however, increase CPU usage considerably, more than OpenVPN, due to its multicore architecture. How this affects other processes when the device is under load due to other applications and services remains to be tested. With OpenVPN, it is clear the security features are a prominent part of the overhead. However, even with those features turned off, it does not outperform a full version of WireGuard. Mobility related concerns were discarded by the tests, since access point switches did not cause issues in any of the conﬁgurations tested, if the latest software versions were used. Unfortunately, since Veniam’s platform was in the midst of a considerable upgrade during the development of this dissertation, it was not possible to get access to an OBU to implement these solutions. The old platform appeared to be incompatible with WireGuard, and the new platform was not deployed in time for testing. The Raspberry Pis used should be comparable to the OBUs in performance, so it is expected similar results would be obtained on Veniam’s platform.

6.2 Future Work

Since the theme of this dissertation was proposed by Veniam, the conﬁguration of the most suitable VPN solution in the OBUs, and its deployment on Veniam’s ﬂeets are logical next steps. A validation of the experimental results in this real-world scenario should follow the deployment. As a deployment on the Veniam network may require tests in a vehicular scenario, testing mobility in the open - for example, driving a connected car over an area of the city, connecting to

29 30 Conclusions and Future Work

Table 6.1: Average penalty per metric compared to plain Ethernet (lower is better)

Full OpenVPN Auth-only OpenVPN Insecure OpenVPN Wireguard Metric penalty penalty penalty penalty Throughput 69,22 55,80 42,17 4,37 (%) CPU Usage 14,8 12,3 11,5 26,6 (pp) Latency 116,3 102,22 97,23 77,58 (%) different Wi-Fi networks -, may prove to be more precise than forcing route changes on the client device. This was not carried out because of the complexity and cost of the set-up. While the literature review was not very favourable to IPSec, it is widely used, and an industry standard. It should handle mobility equally well, if MOBIKE is used. However, it is unlikely to outperform WireGuard. It is also more complex and prone to conﬁguration errors. Since IPSec does not create a virtual network interface like OpenVPN and WireGuard, the testing methodology would have to be adapted. Nevertheless, the addition of IPSec to this benchmark would provide a more complete picture. If security is added on a different layer, and repeated encryption or authentication is seen as excessive, the WireGuard source code may be altered to disable some security features, further reducing its footprint on the system, possibly improving performance. Other new, experimental, niche, or proprietary solutions could also be benchmarked and added to the comparison, if any interesting proposition is found. References

[1] T. Berger. Analysis of current vpn technologies. In First International Conference on Avail- ability, Reliability and Security (ARES’06), page 8 pp., 2006. doi:10.1109/ARES.2006. 30. [2] Congestion charge. URL: https://tfl.gov.uk/modes/driving/ congestion-charge. [3] How will delhi’s ’odd-even’ car rationing work?, Dec 2015. URL: https://www.bbc. com/news/world-asia-india-35198605. [4] João Barros. Connected cars will come before 5g, May 2018. URL: https://veniam. com/connected-cars-will-come-before-5g/. [5] S. Narayan, C. J. Williams, D. K. Hart, and M. W. Qualtrough. Network performance comparison of vpn protocols on wired and wireless networks. In 2015 International Con- ference on Computer Communication and Informatics (ICCCI), pages 1–7, 2015. doi: 10.1109/ICCCI.2015.7218077. [6] I. Kotuliak, P. Rybár, and P. Trúchly. Performance comparison of ipsec and tls based vpn technologies. In 2011 9th International Conference on Emerging eLearning Tech- nologies and Applications (ICETA), pages 217–221, 2011. doi:10.1109/ICETA.2011. 6112567. [7] A. Zúquete and C. Frade. Fast vpn mobility across wi-ﬁ hotspots. In 2010 2nd International Workshop on Security and Communication Networks (IWSCN), pages 1–7, 2010. doi: 10.1109/IWSCN.2010.5497995. [8] I. Coonjah, P. C. Catherine, and K. M. S. Soyjaudah. Experimental performance comparison between tcp vs udp tunnel using openvpn. In 2015 International Conference on Computing, Communication and Security (ICCCS), pages 1–5, 2015. doi:10.1109/CCCS.2015. 7374133. [9] S. Zhou and J. Luo. A novel ip over udp tunneling based ﬁrewall traversal for peer-to-peer networks. In Proceedings of 2013 IEEE International Conference on Service Operations and Logistics, and Informatics, pages 382–386, 2013. doi:10.1109/SOLI.2013.6611444. [10] A. Alshalan, S. Pisharody, and D. Huang. Mobivpn: A mobile vpn providing persistency to applications. In 2016 International Conference on Computing, Networking and Communi- cations (ICNC), pages 1–6, 2016. doi:10.1109/ICCNC.2016.7440684. [11] Daouda Ahmat, Mahamat Barka, and Damien Magoni. Mobile vpn schemes: Technical analysis and experiments. In International Conference on e-Infrastructure and e-Services for Developing Countries, pages 88–97. Springer, 2016.

31 32 REFERENCES

[12] R. Moskowitz and P. Nikander. Host identity protocol (hip) architecture. RFC 4423, RFC Editor, May 2006.

[13] A. Alshalan, S. Pisharody, and D. Huang. A survey of mobile vpn technologies. IEEE Communications Surveys & Tutorials, 18(2):1177–1196, 2016. doi:10.1109/COMST. 2015.2496624.

[14] Jason A Donenfeld. Wireguard: Next generation kernel network tunnel. WireGuard, 2018. URL: https://www.wireguard.com/papers/wireguard.pdf.

[15] Jason A Donenfeld. Wireguard: Next-generation secure kernel network tunnel - netdev presentation, 2017. URL: https://www.wireguard.com/talks/ netdev2017-slides.pdf.