Speed, security and high availability considerations for

The cipher and its encryption mode strongly aect the performance of a VPN. A number of groups have measured the throughput in open source IPsec so- lutions. Libreswan is reported to have reached 5.25 Gbps throughput using AES-GCM-128 and 1.39 Gbps using AES-128-CBC in [87]. In turn, [169] has measured Strongswan as reaching 9.6 Gbps using AES-GCM in New Instruc- tion (AES-NI) mode. The Wireguard project has measured the performance of

an unspecied IPsec solution as reaching 881 Mbps with the AES-256-GCM- 128 cipher using AES-NI [176]. The choice of hardware has a signicant eect and thus explains the wide range of dierent results. In order to determine the maximum throughput, it is even more important to see whether they were all using GCM mode rather than CBC or some other mode. This clearly indicates that the use of GCM mode is preferred to gain higher throughput for VPN solutions.

OpenVPN is not regarded as the fastest VPN tunneling solution based on benchmarks like [176] and [16]. The Wireguard project [176] has benchmarked OpenVPN reaching 258 Mbps with their setup using some 256-bit AES cipher. OpenVPN was also benchmarked by the BSD Router Project (BSDRP) [16]. They achieved 550 Mbps throughput using AES-GCM-128 mode in their test setup.

OpenVPN has a number of known vulnerabilities as reported in, for instance, [120] and [116]. Some of these vulnerabilities are not specic to OpenVPN but aect a wide range of services through a common library like OpenSSL instead. OpenVPN often utilizes OpenSSL as well, but alternative TLS libraries can be used. Furthermore, OpenVPN is vulnerable to DoS attacks, as is almost any public service.

The IPsec suite has been heavily criticized by Ferguson and Schneier [44] be- cause of its very complex structure, which can even decrease the overall security. There have been actual attacks against IPsec, as in Felsch et al. [43], for exam- ple, who found that it is possible to break into the IKE protocol and achieve authentication bypasses. In addition to these protocol weaknesses, software projects providing IPsec suites often suer from a number of vulnerabilities. For instance, Strongswan has been reported as having remote denial of service up to version 5.6.0 [102].

In addition to targeted attacks, devices running VPNs are also susceptible to possible hardware or software failures, which can cause the service to be temporarily unreachable. To mitigate these problems, a High Availability (HA) [66] feature has been added to the picture. Its purpose is to run another instance of the service on another device. Although HA does not guarantee 100% uptime, it does guarantee 99.999% , which means that only minimal service breaks of a few seconds need occur in an error situation [53]. HA can also be extended

to include load balancing [66]. The main dierence here is that HA provides a service to stay up even if some part of the infrastructure running the service crashes. The load balancing ensures that the workload will be shared among the available resources.

HA and load balancing are quite cumbersome in IPsec cases, as stated in [100]. Document scopes the problem of an IPsec cluster oering both fea- tures. First of all, the SAs of an IPsec should be synchronized between the cluster nodes to ensure seamless operation. That is still only a minor prob- lem compared to the diculty of synchronizing the ESP packet SA counters. These counters are incrementally numbered, making the packets unique and thus adding an anti-replay feature to the protocol. However, their exact syn- chronization requires a lot of overhead from the servers, even if it is possible at all [100].

Instead of counter synchronization after every ESP packet, Nir [100] suggests synchronizing the outbound SA counters after every 10,000 packets or so, and learning the counter value from the packets going to the incoming SA counter. So, the anti-replay feature makes load balancing cumbersome, or even impos- sible. The other cluster members cannot process the packets uently without updated SA counter values. It is possible to disable the anti-replay feature as permitted in [80] but this is very risky due to the security vulnerabilities that this exposes.

While acknowledging that IPsec ts poorly into an HA setup, the Strongswan project has nevertheless looked at HA deployment in [164]. Their solution re- lies on having one virtual IP throughout the cluster servers to run the IPsec. A customized high-availability plug-in is used to to share state information and the SA of IKE with the IPsec SAs throughout the cluster. The outgoing ESP packets are kept on one node to enable sequential numbering. When this node goes down, the number is lost and in the re-join phase new IPsec SA (or CHILD_SA) re-keying takes place. The incoming SA counters on the clus- ter nodes are updated from the incoming packets every now and then, which provides adequate counter information and therefore the essential anti-replay security feature [100].

The OpenVPN community edition presents a load balancing and failover conguration in [119]. The principle is to have multiple remote server ad-

dresses for the client conguration, and the client picks one from the list to connect to. However, this kind of approach is not regarded as true load balanc- ing since the clients randomly pick a server without knowing its load status. Such a mechanism creates an uneven distribution of clients to the pool of Open- VPN servers. Furthermore, the server software is unaware of the other possible servers in the cluster and thus cannot make client hand overs in order to share the load equally. Although the failover feature is present, if a server goes down the OpenVPN tunnel must be re-negotiated with some other server.

2.4 Time to make tasks faster: Hardware