Want to keep your data safe? Here’s how VPNs and IPsec have your back!
In recent years, the number of people working remotely has significantly increased. These remote workers access their company’s network to perform their duties. However, this increases the risk for companies because an attacker can eavesdrop or even intercept while the employee is accessing the data on the company’s network.
To avoid this situation, organizations use a virtual private network (VPN). A VPN is basically a tunnel/private network in which the data traveling through this private network is concealed from the outside world. VPN is a virtual network established on the existing physical network. (It’s like requesting a private meeting room within a public library.)
There are two primary ways to use a VPN:
Regardless of whether a remote access VPN or site-to-site VPN is used, the VPN secures the data by creating a virtual (or logical) tunnel. This tunnel or secure communication is created using a set of protocols. At a high level, these protocols work similarly to the TLS protocol you learned about in the previous section.
In the cloud or dynamic environment, software-based VPN architectures are gaining popularity. This type of architecture is called a software-defined network (SDN). In an SDN, there are no VPN servers, but software controllers (SC) manage the authentication and connection parameters for the hosts. Hosts then negotiate the key exchange and set up the connection.
SDN is a very attractive alternative to hardware-based VPNs. The SDN-based networks, including VPNs, can be set up easily. In the cloud and other shared/virtual environments, this helps because SDNs allow cloud providers to easily set up, manage, and tear down VPNs at any time.
The computers exchange traffic with each other on a network using logical addresses (IP addresses) and physical addresses (MAC addresses). When the networking models, such as the OSI model and TCP/IP, were designed, the goal was to move traffic from one network to another network in the most efficient way. All focus was on efficiency and accuracy. Security of the traffic probably didn’t make the list of the design criteria or priorities, but rather was added later on. This resulted in a “bolt-on” security as opposed to a “built-in” security. Internet Protocol Security (IPsec) is a good example of bolt-on security.
IPsec was first published by IETF RFC 1825 in 1995 and later RFC 2401 in 1998. IPsec operates at the network layer (OSI model) or internet layer (TCP/IP model) [RFC 4301, 2005] [Dhall, 2012]. IPsec is a suite of protocols, primarily including the following:
Additionally, IPsec works in two modes—transport mode and tunnel mode. In transport mode, the data packet retains the original IP address, and only the data is encapsulated. On the other hand, in tunnel mode, the entire packet, including the original IP address, is encapsulated. The source router or the gateway assigns the new IP address of the destination router or the gateway. Once the messages reach the destination gateway or the VPN server, the packet is decrypted, and the data is routed to the original IP address. A quick overview of tunnel mode and transport mode VPN is given in this table.
Under the hood, the IPsec protocol, like the TLS protocol, uses the fundamental components of cryptography—symmetric encryption, asymmetric encryption, and hashing.
The process of setting up a VPN using IPsec starts with the IKE protocol. IKE uses other key exchange protocols, such as the Internet Security Association Key Management Protocol (ISAKMP), Oakley protocol, and Security Key Exchange Mechanism (SKEME) protocol. The Oakley protocol is focused on the Diffie–Hellman key exchange while the SKEME is more versatile and offers more options for key exchanges. ISAKMP is a framework for the authentication and key exchange.
In this part of the process, both ends (i.e., the client and the server) work on authentication and negotiating the key parameters. It’s in this phase that we confirm or authenticate the sender and negotiate the key parameters. Does this sound like a TLS handshake process? It probably does because it’s a very similar implementation here; however, it operates on a different network layer.
Like the TLS handshake, the authentication is achieved by a public key or a digital certificate. To generate the symmetric key or the shared secret—to be used later to encrypt the data or the payload—the Diffie–Hellman (or something similar, e.g., the ECC) method is used. The public parameters—prime number p, generator g, and the public key—are shared in this step of the process. If everything goes well, then at the end of this step, a security association (SA) is established; in other words, a connection is formed between the two parties.
The SA is a simplex communication link that sends data in only one direction. To establish a two-way communication, two SAs must be set up—one for each direction. The SAs have the following properties:
Once the heavy lifting of key authentication and key exchange is completed, phase 2 of setting up of VPN begins. In this part, the other two protocols are used: Authentication Header (AH) and Encapsulating Security Payload (ESP).
The AH protocol adds the authentication and integrity data as the header of the packet. This figure shows the AH protocol.
The AH passes the data or the message through the hash function. The generated hash function is encrypted with the symmetric key, and the encrypted hash digest is appended as a header to the message. The data itself is still in the clear text. The receiver receives the message with the authentication header as part of the packet. The receiver decrypts the digest value with a symmetric key. The unencrypted hash value is sent through the same function and compares the generated hash value with the received hash values.
If the values are the same, then the data isn’t modified along the way. This provides data integrity. Additionally, the hash function is a keyed function, and the same symmetric key is used by the sender and the receiver. If the receiver can use the key to extract the hash digest, then it assures that the packet came from the right sender. This authenticates the sender. The symmetric key is generated in the previous phase using the IKE protocols.
The most important protocol of IPsec is ESP. The message sent using the AH protocol is in clear text and doesn’t provide confidentiality. In fact, the National Institute and Standard Technology (NIST) discourages the use of the AH protocol in implementing IPsec [NIST 800-77, 2020]. The recommendation is to use ESP protocol, which encrypts the message and provides confidentiality.
The next figure shows the header structure of the ESP protocol. The encapsulated data is sent either using the transport mode or the tunnel mode. In the transport mode, the original user IP address is visible, while in the tunnel mode, everything is encapsulated, and the new source and destination IP addresses are assigned.
If TLS and IPsec both do almost the same things, then why do we have two protocols? This is a valid question. The TLS protocol operates at a higher level of the OSI and TCP/ IP models—between the application and transport layers. On the other hand, the IPsec protocol operates at the network/internet layer. The higher the protocol, the less likely data is to be secured.
The TLS protocol encrypts only the application data while the IPsec protocol, even in the transport mode, encrypts everything except the IP address and encrypts the entire packet, including the IP addresses in the tunnel mode. TLS is primarily used for point-to-point communication, such as from browser to server. IPsec is used to connect to an entire network.
The last and probably the least used IPsec protocol is IPComp. This protocol is considered if the data needs to be compressed. It doesn’t compress the packet if the message is small; it only tries to compress the larger packets. Many different compression algorithms are used, and if the compressed data is larger than the original data, then the compression is skipped even for a bigger packet. Data is encrypted after compression if data is compressed.
IPComp adds overhead and can slow down the process. In most cases, when a very large amount of data is to be transmitted, it’s efficient for the application to compress the data. Research efforts are underway to develop efficient compression algorithms that can be used with Internet of Things (IoT) devices.
Editor’s note: This post has been adapted from a section of the book Modern Cryptography: The Practical Guide by Sandip Dholakia.