Virtual private network evokes certain ideas from different folks. Some will think ISAKMP/IPSec GRE tunnels while others will think VRFs and MPLS. I had used VPNs as a consumer for several years before I started to study them for networking. If you’re using a program like NordVPN then that is more the first type than the second.
I remember the first time seeing an illustration for an SSL VPN. There were two tunnels, a bunch of acronyms and endpoints. It was a typical slide in a networking lecture. I was somewhat comfortable with all the TLAs (three letter acronyms) involved having seen so many of them already but the two phase tunnel was a mystery to me. I could have just accepted that an SSL VPN required two phases and memorized what I needed to but my brain doesn’t work like that. I need to know why.
Here are the facts. The two endpoints want to encrypt their traffic. They both need to agree on an encryption key in order to encrypt and decrypt the traffic. How do they agree on the encryption key if the connection between them is insecure? It has something to do with the parameters that are configured in the ISAKMP policy which allows everything from the encryption method to the lifetime of the connection to be configured. Setting the encryption algorithm is understandable but what does that group number mean?
After a bit of reading, I discovered that the majority of the information required to coordinate the common session key involves this mysterious Diffie-Hellman group. There is some abstract algebra and number theory involved but a Diffie-Hellman group is just a set of numbers. Each group corresponds to a large prime number and both endpoints have to agree on a special number in the group called the primitive element. Each side then chooses a random number in the group and uses the primitive element and the prime number to calculate a number. That number is then sent in clear text to the other endpoint. When the two numbers are combined, they allow each side to commute the common session key.
The truly interesting part of this exchange is that most of it is done in clear text. The only things kept secret are the one number that each side chooses. The Diffie-Hellman exchange relies on what’s called the discrete logarithm problem. In a nutshell, even if a third party were to collect all of the information exchanged between the endpoints, it would still be extremely unlikely that the remaining information and the common key can be derived!
Certain sets of numbers actually allow attackers to circumvent the discrete logarithm problem and transform the problem into a much easier one so there are recommendations for avoiding certain Diffie-Hellman groups.
If you’re interested, you can read up on the discrete logarithm problem and the difficulty in factoring large prime numbers. It’s fascinating stuff but not anything you’d use in your day to day as a network engineer. I used Understanding Cryptography, a textbook for students and practitioners by Christof Paar and Jan Pelzl. It goes into the details and also the attacks against the Diffie-Hellman key exchange along with break and butter concepts like the AES and RSA algorithms.
After having that common session key, the second tunnel can be established. This is standard encryption/decryption and has its own set of encryption/hashing parameters that need to be exchanged. It’s interesting that two IPSec security associations are established between every pair of endpoints. I do wonder why the authentication header is an option for IPSec since the encapsulating security payload does what AH does as well as encrypt the body of the packet itself.
To recap, the first ISAKMP tunnel is used to generate the common encryption key over an insecure connection. The second IPSec tunnel is completed encrypted from start to finish and, thanks to the first phase, can exchange security parameters directly, including the encryption key. IKEv2 allows all of this to happen in one phase but I have yet to investigate how that works yet. The takeaway here is that the VPN established is a private network because the traffic is encrypted. It is the answer to ensuring data integrity over a public network.
The configuration is somewhat complex but learning the reason behind why each thing is configured makes the process a lot easier to remember. As I studied more and more complicated configurations, the proportion of time I spent learning the theory behind the process started to dwarf the configuration time.
I’ll end it here for now. As I’ll discuss in the next post, the MPLS deployment is a private network in a completely different sense.