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 la-tency 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, de-vice 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 Table3.1, and comparing the performance in Table3.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
10 Literature Review
Table 3.1: Results of basic functionality from Berger [1]
VPN Technology Vendor Init
-to reconnect au-tomatically. Throughput also suffered a dramatic reduction, from 94 Mbits/s with-out 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 penal-ties, 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].