IPsec is a both a standard VPN framework as well as a specific protocol that has existed for quite some time and at its core has changed very little. It can trace its origins to somewhere about 1993 when the first IP VPN protocols, such as SP3, NLSP and swipe, were being developed. Eventually and early predecessor ka9q would contribute to the development of the first true IPsec designated by the IETF (Internet Engineering Task Force) in 1995, as recorded by Columbia University. 1998 would see additional revisions, sequencing and improvements in authentication; but it would not be until 2005 that IPsec really came into its own with the release of version 3, which again updated algorithms and larger sequencing numbers. Because it has never been bound by particular protocols, IPsec continues to be malleable allowing for newer and more secure technologies to be applied to its foundations.
IPsec is an extremely popular VPN protocol that functions using the IP protocol and its addressing and therefore can be considered a ‘Network Layer’ VPN protocol. IPsec is actually not bound to any particular protocols necessarily but is an openly available set of protocols and standards which can be used with many different combinations. The Entire Framework for IPsec can be classified into 5 major sections:
- The actual IPsec protocol
- The type of confidentiality used such as DES, 3DES or AES
- Integrity of the data using MD5 or SHA
- Secret Key Establishment
- Key Exchange
The above list of 5 depicts a pretty accurate summary of the framework, however we want to focus in on the 3 main goals of IPsec. Like many VPN technologies its main concern is secure communications, which is achieved using the following: Confidentiality, Integrity and Authentication – ironically this is most easily remembered using the acronym CIA. Beyond this CIA trio, we must always remember there will also be a Secure Key Exchange in the process. To properly understand IPsec we will explore the CIA trio and touch on the key exchange function:
- Secure Key Exchange
If you look back to the introduction we mentioned the evolution of IPsec often attributed to updated algorithms and longer sequence numbers. Confidentiality is obviously concerned with the privacy or secrecy we seek by using VPNs. In IPsec, like other frameworks, this is achieved depending on the key length and the strength of the encryption algorithm used. Like any other password, key, etc. attackers will test for short or weak keys using methods like brute force attacks or possibly something more elegant like rainbow tables. Like passwords, a short and simple key can be guessed more easily, where a longer more complex key becomes harder to guess and therefore harder to crack. According to Cisco’s CCNA Security a 64-bit key could be potentially cracked in one year using if a complex and powerful computer is left constantly guessing. One might think that a key with twice as many bits might take 2 years (twice as long) or even 10 years (ten times as long) to crack with the same computer; but it would actually take roughly 10¹⁹ years to decrypt. In computers and networking adding just one character to a password or key increases its security exponentially. As we mentioned, the IPsec framework is not bound to any specific algorithms, therefore it’s easily advanced and improved; hence its popularity.
The most common encryption algorithms used include DES, 3DES and AES. DES, which stands for ‘Data Encryption Standard’, is probably the least popular as it only uses a 56-bit key; however its shortened key length means that less overhead is created and in turns this shortens everything else included the integrity confirmation (checksum). This makes DES a good choice for low bandwidth or extremely time sensitive scenarios, where some security can be sacrificed for speed. 3DES is an improvement on DES and as its name suggests it actually uses 3 separate DES-based encryption keys – still at 56-bits per key. This would be more secure, but also more time consuming and cumbersome as there are now 3 keys to deal with. AES (short for ‘Advanced Encryption Standard’) seems to be the best of both worlds and is arguably the most popular of the 3 today. AES is absolutely stronger than DES and still more efficient than 3DES. On top of that, AES provides more choice in its key lengths: 128, 192 and 256-bits. In networks where security trumps all else, you will see most use AES at either 128 or 256-bits, although there are likely specific applications of DES and 3DES still today.
With Confidentiality sorted out the next major concern is the integrity of encrypted data. Like all common TCP traffic, IPsec needs to ensure that all of the data arrives to its destination and that it can be properly reassembled and ordered to then be passed on the to the upper Layers and eventually recompiled into something the user can understand. Unlike UDP traffic, TCP protocols make sure that all data arrives properly using checks; and if it’s not then it will often be resent. IPsec Integrity builds on this idea except it’s also specifically concerned with interception and tampering of data. A Man-in-the-middle attack can describe an attacker knowing how to not only sniff data in transit; but also to possibly intercept and change that data for some malicious intention. It will eventually still arrive at its destination, but it might be modified to now be inaccurate or could even be injected with malicious code depending on the scenario. The IPsec Framework is put in charge of preventing this, so not only does it ensure the accuracy of your traffic, but it also protects it from malicious collection, deletion or modification. In the same we confirm a Linux ISO download using an MD5 checksum, IPsec confirms the accurate transmission and receipt of traffic; except that it does this securely using either HMAC-MD5 or HMAC-SHA. HMAC stands for Hashed Message Authentication codes, but what separates an MD5 checksum and an HMAC-MD5 checksum is a secret key exchange between sender and receiver. Again, the choice between algorithms really boils down to older vs newer and less secure vs more secure. HMAC-MD5 uses a 128-bit key and was created by Ronald Riven, where HMAC-SHA has grown into multiple versions ranging from 160-bits to 256-bits. As you can probably guess, SHA-256 is currently considered a secure standard and is possibly the most common HMAC in use for IPsec VPNs. Like all things security, these protocols and algorithms are quite useless without some type of proof that the sender and receiver are who they say they are and like most levels of computing these days the IPsec Framework would not be complete without the key to the door: Authentication.
IPsec would not be complete or really even useful without Authentication – actually it would be much like having a deadbolt, a door chain and a doorknob lock and leaving them all unlocked or perhaps just using the doorknob lock, which is not quite as hearty as the deadbolt. IPsec commonly provides authentication one of two ways: either by using a PSK (Pre-Shared Key) or by using RSA certificates coupled with a key. A PSK would be chosen (or generated) and then keyed in on either endpoint of the IPsec tunnel. For many home or small office operations this is sufficient and plenty secure, providing that the key is complex. RSA using digital certificates is quite a bit more secure, because without a generated certificate, the key will not suffice. The certificate is used to allow encryption and decryption using the presence of said certificate. The encryption and decryption occurs using private and public keys, similar to how PGP operates. This is more secure and much more scalable than a PSK, which makes it a popular choice for larger networks. Whether you’re using a consumer-based VPN client or an always active site-to-site IPsec tunnel between two routers (FIGURE B), RSA would always be a more secure choice if available.
In order to use any sort of shared key for VPN, a secure method must be chosen to share the key. It wouldn’t be particularly secure to email or instant message a key, as these would likely be transmitted in plain text by default or could be intercepted in various ways. Physically mailing or driving/flying the key to another endpoint wouldn’t really work in many scenarios either, so how do you agree on a key? Even before a tunnel is established it is possible for both endpoints to exchange keys using the DH (Diffie-Hellman) method. Public keys are exchanged on either end to encrypt data, but only each endpoint has the private key to decrypt it. This means that if an attacker were to intercept the public key exchange it would be absolutely useless to them, where it would only allow them to encrypt data using that key set. Ironically, they would have no way to even decrypt their own message again once it has been encrypted. Again, this functions very similar to PGP, which many readers are probably more than familiar with.
It doesn’t take a genius to understand the basic principles of VPNs and how they protect us. VPN tunnels can be simple tools used just for basic protection and privacy or they might be complex and expensive solutions that allow businesses to virtually extend their private networks all over the world. Even when we dig down a bit further and start to look at specifics like the IPsec Framework, it’s still actually still quite understandable providing you don’t start digging down to the level of mathematical functions that allow these algorithms to work. I will leave that for another author for another audience. My goal here was simply to pick out a very popular VPN technology and peel back some of the mystery. Now when you’re choosing a VPN provider, you will have some idea what it means if they support a SHA-256 AES tunnel. I hope that this has been informative and mostly accurate, but no matter what VPN protocols you choose the important thing is that we increase the use of safe interment technologies like VPN and TOR, because like the TOR people keep saying (and I’m paraphrasing): the more people who regularly use TOR, the more anonymous it becomes. Most of us now know that a safe internet experience means at least TOR and VPN together, but it’s fair to say that the same principle can be applied to VPN.
CCNA Security v. 1.0, Cisco Press, 2011.