Performance and Strength Comparison Of Various Encryption Protocol of PPTP VPN. Anupriya Shrivastava,M A Rizvi National Institute of Technical Teacher s Training and Research Bhopal, India 1, 2 anushrivastava1989@gmail.com 1, marizvinitttr@bpl.ac.in 2 A B S T R A C T In order to prevent spoofing and hacking of the data, OSI model provides numerous security protocols such as Internet Protocol Security (IPSec) in network layer and Socket Secured Layer (SSL) in transport layer etc. There are a large number of ways to implement the Virtual Private Network (VPN) that create the illusion of a private network within public domain. One such protocol is Point to Point Tunneling Protocol (PPTP). An attempt has been made in this paper to compare the performance of various encryption protocols in Point-to-Point Protocol based Virtual Private Network. We analyze the latency values for different protocols. Next we compare the relative cryptic strengths of each of these protocols and show that compromising on the security does not result in much gain in data rate. Index Terms: MPPE; PPTP; RC4; Cipher; VPN; MSCHAPv2 I. INTRODUCTION Remote access is common need for the traveling persons like businessman, directors who desire to get connected to their organizations private network from far-off locations. Due to the valuable information it carries, the security issues must be considered carefully. One of the popular technologies used to achieve these goals is VPN. A private network is extended across a public network, as the Internet, through VPN [5]. This allows sharing of data in public networks as if they were directly connected. Some popular VPN technologies include PPTP, which works on port TCP 1723 [6], Layer 2 Tunneling Protocol (L2TP), Internet protocol security (IPSec) and Secure Socket layer (SSL). Several commercial and open Source VPN products are now available that can be configureured to provide VPN services with varying characteristic [7]. Although a great deal of work is being done to standardize the VPNs, neither of the trusted VPN technologies are IETF standards yet [8]. Implementation of VPN are done through different technique, Point-to-Point Tunneling Protocol (PPTP) is one of method for implementation. To encapsulate PPP Packets, PPTP uses a control channel over TCP and a GRE tunnel. PPTP protocol is being tunneled to implement functionality such as security. Encryption or authentication features are not specified by PPTP protocol. Being a Microsoft implementation, the PPTP package that comes shipped-in with the Windows Operating System has varying degrees of authentication and encryption protocols. The primary intention is to provide to the VPN users a kind of security and access from far-off locations (remote) that are found in any state-of-theart VPN technology. The encryption protocol - Microsoft Point-to-Point Encryption, as suggested by the name, was an initial Microsoft implementation. But, it is now available in all common Operating Systems such as Linux. Even android-based devices come built-in with PPTP software. 1 2014, IJAFRC All Rights Reserved www.ijafrc.org
Figure 1. Setting up PPTP VPN in android-based mobile MPPE encrypts data in Point-to-Point Protocol (PPP)-based dial-up connections or Point-to-Point Tunneling Protocol (PPTP) virtual private network (VPN) connections. Supported encryption scheme for MPPE are 128-bit key (strong), 56-bit key, and 40-bit key (standard). Between VPN client and VPN server there is a data security for PPTP connection that is provided by MPPE. II. RELATED WORK Author [1] provides the information regarding the availability of patches under Linux that allow PPP to support RC4-compatible 40, 56 and 128 bit encryption. As PPTP uses PPP so some people makes the mistake of assuming that there is a need of a modem but that is no longer essential. Moreover, the methodology used to connect to the IP network is transparent to PPTP. Figure 2 shows the IP packet frame with encrypted portion. Figure 2. PPTP packet format with encryption Pall and Zorn, [2] have shown in the RFC how the length of the session key to be used for initializing encryption tables can be handled.128-bit and 40-bit session keys are currently supported by MPPE. Thambiraja, Ramesh and Umarani [3] in their research paper, have shown that RC4 is faster and more efficient protocol compared to AES for encrypting large packets. Throughput for encryption, work load by CPU, cost for energy and variation in key size were the performance metrics used by them. Also, they have shown that RC4 takes less time to encrypt the files. Thus, we can conclude that MPPE, which internally uses RC4, is a better protocol as compared to other AES protocols for heavy traffic networks. 2 2014, IJAFRC All Rights Reserved www.ijafrc.org
Figure 3.Algorithm to derive cipher text from key using RC4 Nadhem, Daniel, Kenneth, Bertram and Jacob [4], showed that single-byte bias attack on RC4 is quite effective in recovering early plain-text bytes in the fixed-plaintext multi-session setting. Dr. Sabah Nassir Hussein FCMI and Abdul HadiQais Abdul Hadi [10], in their research paper used the security protocol PPTP, L2TP and IPSec on dedicated private network and VPN to see the impacts on those two networks. Performance test result of the private network is implemented using OPNET Version 14.0 by simulating two different networks and applying different security protocols. Using OPNET they measure the efficiency of performance and Quality of service (Qos) of the networks that are implemented for this purpose they have shown different output for security protocols like voice conferencing jitter, mean opinion score (MOS), Download response time across the network, FTP download response time and video conferencing packet delay variation for security protocols PPTP, L2TP and IPSec. III. WORKING OF MPPE ENCRYPTION MPPE alone does not expand or compress data, but the protocol is frequently used in conjunction with Microsoft Point-to-Point Compression which compresses data across PPP or VPN links. Negotiation of MPPE happens within the Compression Control Protocol (CCP), a sub protocol of PPP. This can lead to incorrect belief that it is a compression protocol. RC4 is the most widely used software stream cipher incorporated in MPPE as well. Once an initial session key has been derived, then the initialization RC4 contexts are as follows: rc4_key (RC4Key, Length_Of_Key, Initial_Session_Key) The encryption of data is performed using following function: Data (encrypted) = f (rc4 key, data length, data) where f =rc4 It can be observed that the length of the key is a critical parameter in determining the encryption strength because of which we prefer using 128-bit MPPE over 40/56-bit MPPE protocol. So during stateful synchronization RC4 tables are reinitialized, now it is possible using the same key two different packets may be encrypted. For this reason, in lossy network environments the stateful mode SHOULD NOT be used for this condition layer two tunnels on the Internet can be an example. IV. EXPERIMENTAL SETUP Dell Precision T3610 system is used with, Intel Xeon processor E5-1600 v2, 32 GB RAM, for both client and server systems. Operating system Windows Vista machine is configureured as a PPTP Server by using the Incoming Connection functionality. A pool of addresses is assign in the IP address range P.Q.R.S P.Q.R.Z from which Server will select starting IP for itself and one among the remaining for 3 2014, IJAFRC All Rights Reserved www.ijafrc.org
Client. Operating system Windows 8 is configureured as a PPTP Client. In the cases studied, we vary the encryption option from the Properties section of the Client. Next, a connection is established from PPTP client to PPTP server. Connection between client and server occurs in three phases: Phase 1: Connection initiation by VPN client and determination of authentication protocol to be used. Firstly Establish a TCP connection between client and server. The message format will be Msg = F (Server IP, Server Port).Then VPN client sends a connection request to VPN server, If the VPN server is up and running, it responds back with connection reply. Now client and server decide upon the link control parameters. Then VPN client suggests the authentication (such as PAP, MSCHAP) and encryption (such as MPPE) protocols. The message format will be: Msg = F (Auth Proto = a1, a2 an Encryption Proto = e1, e2 en); Now server will decide to communicate with client using any or all of the above mentioned protocol, it responds back to the client with one of the following messages: a) ACK : in case of straight agreement (agrees to one/any among a1, a2... and one/any among e1, e2 ); b) NACK : in case it want the client to choose another protocol; REJ: in case it wants to reject the connection, this is shown in Figure.4. Figure. 4. First phase of PPTP, post TCP connection Phase 2: This is an authentication phase where the authentication is performed between Client and Server using PAP, CHAP or MSCHAP protocols. The user credentials sent may be in plain-text format or encrypted depending upon the protocol chosen. Phase 3: Once the authentication is successful, virtual interfaces (of the form pppx) are brought up. Server assign an IP to the client and itself from the pool of free IPs. To verify the status of VPN connection can be checked as follows is shown in Figure.5 4 2014, IJAFRC All Rights Reserved www.ijafrc.org
Figure 5: Properties can be viewed on Status tab in Windows Next we run a stream of ping traffic using the command: Ping <Client IP> -n 1000 Two scenarios are considered with same authentication protocol: MSCHAPv2 but different encryption protocols: MPPE-40 bit and MPPE-128 bit. CASE 1: Figure 6 shows the output taken on a networking tool Wire shark when MPPE-128 bit encryption is chosen. The X-axis shows the time illustrated in the HH:MM:SS format with 1 tick interval = 10 seconds. Y-axis shows the number of packets per tick. As time increases, the graph shifts towards the left and the most recent capture appears on the right hand side. Figure 6: Wire shark I/O result showing the amount of Bytes transferred with time (MPPE 128) V. OBSERVATION The average number of IP packets transferred per tick interval is around 100 with occasional peaks at the rate > 250 packets/tick. Also there are a few dips which show that the data rate is suddenly lowered when PPTP control packets are transferred. CASE 2: Figure 7 shows the output taken on a networking tool Wire shark when MPPE-40 bit encryption is chosen. The X-axis shows the time illustrated in the HH:MM:SS format with 1 tick interval = 5 2014, IJAFRC All Rights Reserved www.ijafrc.org
10 seconds. Y-axis shows the number of packets per tick. As time increases, the graph shifts towards the left and the most recent capture appears on the right hand side. Figure 7: Wire shark I/O result showing the amount of Bytes transferred with time (MPPE 40) The average number of IP packets transferred per tick is around 70, which is around 25 % better than that observed in case of previous stronger protocol. Though, there are certain peaks as well which shows that the weaker encryption does take significantly less time in between. Again, a few dips can be observed where the data rate gets reduced to < 10 packets/tick due to the transfer of control packets. VI. CONCLUSION AND FUTURE WORK With an ever increasing risk of attacks on VPN traffic, it is imperative that the user must ensure that the encryption and authentication protocols are strong enough to be able to withstand such attacks. The experiments shown above also suggest that one should opt for a weaker encryption protocol only if either one of the Server or Client does not support a stronger one. Though the experiment has been performed for PPTP, the results very well apply to L2TP as well because both use PPP protocol for encryption. There is scope for improvement with respect to the strength of MPPE protocol. It makes use of RC4 stream cipher. There exists no authentication method for cipher text stream. As a result of which the bit-flipping attack can expose its vulnerability. The stream can be modified by an attacker in transit and can manipulate single bits so as to modify the output stream with hardly any possibility of detection. VII. REFERENCES [1] [Online] Available: http://www.linuxjournal.com/article/3965 [2] [Online] Available: http://www.ietf.org/rfc/rfc3078.txt [3] Thambiraja, Ramesh and Umarani, a Survey on Various Most Common Encryptions Techniques, International Journal of Advanced Research in Computer Science and Software Engineering. [4] Nadhem, Daniel, Kenneth, Bertram and Jacob, On the Security of RC4 in TLS, 22nd USENIX Security Symposium. [5] [Online]Available: http://en.wikipedia.org/wiki/virtual_private_net work 6 2014, IJAFRC All Rights Reserved www.ijafrc.org
[6] K. Hamzeh,G. Pall, W. Verthein, J. Taarud, W. Little, G. Zorn, point to point tunneling protocol.rfc2637(july 1999). [7] Shashank Khanvilkar and Ashfaq Khokhar, Virtual Private Networks: An Overview with Performance Evaluation, 0163-6804/04/$20.00 2004 IEEE. [8] [Online]Available:http://www.vpnc.org/vpn-standards.html. [9] Bruce Schneier, Mudge, and David Wagne, Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS-CHAPv2), Springer-Verlag Berlin Heidelberg, 1999. [10] Dr. Sabah Nassir Hussein FCMI and Abdul HadiQais Abdul Hadi, the Impact of Using Security Protocols in Dedicated Private Network and Virtual Private Network, INTERNATIONAL JOURNAL OF SCIENTIFIC & TECHNOLOGY RESEARCH VOLUME 2, ISSUE 11, NOVEMBER 2013. [11] R. Malhotra, R. Narula, Techno-Evaluation and Empirical Study of Virtual Private Networks Using Simulations, Journal of Computing, Volume 3, Issue 7, July 2011. [12] M. Finlayson, J. Harrison, R. Sugarman,VPN TECHNOLOGIES A COMPARISON" February 2003, updated June 2004. [13] Narayan. S., Brooking, K. ;de Vere, S, Network performance analysis of VPN protocols: An empirical comparison on different operating system, Networks Security, Wireless Communications and Trusted Computing, 2009. NSWCTC '09, International Conference on (Volume: 1). [14] Narayan. S., Brooking, K.; de Vere, S, Network Evolution of VPN Protocols in window 2003 environment, Advanced Computer Theory and Engineering, ICACTE 2008. 7 2014, IJAFRC All Rights Reserved www.ijafrc.org