Technical details: Basic principles of IPSec VPN

IPSec VPN is a technology with a very high click rate among current VPN technologies. It provides both VPN and information encryption technologies. This column will introduce the principles of IPSec VPN.

IPSec VPN Application Scenarios

IPSec VPN application scenarios are divided into three categories:

• Site-to-Site (site to site or gateway to gateway): For example, the three organizations of Ququ Review are located in three different places on the Internet. Each organization uses a Business Navigator gateway to establish VPN tunnels with each other. The data between the corporate intranets (several PCs) are securely interconnected through the IPSec tunnels established by these gateways.
• End-to-End (or PC to PC): The communication between two PCs is protected by the IPSec session between the two PCs, not the gateway.
• End-to-Site (end-to-site or PC-to-gateway): The communication between two PCs is protected by IPSec between the gateway and the remote PC.

VPN is just an application of IPSec. IPSec is actually the abbreviation of IP Security. Its purpose is to provide high security features for IP. VPN is a solution generated under the way to achieve this security feature. IPSec is a framework architecture, which consists of two types of protocols:

• AH protocol (Authentication Header, less commonly used): can provide security features such as data integrity confirmation, data source confirmation, and anti-replay. AH commonly uses digest algorithms (one-way hash functions) MD5 and SHA1 to implement this feature.
• ESP protocol (Encapsulated Security Payload, widely used): can provide security features such as data integrity confirmation, data encryption, and anti-replay at the same time; ESP usually uses encryption algorithms such as DES, 3DES, AES to implement data encryption, and uses MD5 or SHA1 to achieve data integrity.

Why is AH less used? Because AH cannot provide data encryption, all data is transmitted in plain text, while ESP provides data encryption; secondly, AH cannot traverse NAT because it provides data source confirmation (once the source IP address changes, AH verification fails). Of course, IPSec can use AH and ESP at the same time to achieve the most complete security features in extreme cases, but this solution is extremely rare.

IPSec encapsulation mode

After introducing the scenarios of IPSec VPN and the composition of the IPSec protocol, let's take a look at the two encapsulation modes provided by IPSec (Transport mode and Tunnel mode).

The above figure shows the encapsulation structure of the transmission mode, and then compares it with the tunnel mode:

You can find the difference between transport mode and tunnel mode:

• In the transport mode, the IP header remains unchanged before and after AH and ESP processing. This mode is mainly used in end-to-end application scenarios.
• The tunnel mode encapsulates an external IP header after AH and ESP processing, and is mainly used in Site-to-Site application scenarios.

From the above figure, we can also verify the difference between AH and ESP introduced in the previous section. The following figure explains the scenarios in which transport mode and tunnel mode are applicable.

From the comparison of this picture we can see that:

• Tunnel mode can be applied to any scenario
• The transfer mode is only suitable for PC to PC scenarios

Although the tunnel mode can be applied to any scenario, it requires an extra layer of IP header (usually 20 bytes in length) overhead, so in the PC-to-PC scenario, it is recommended to use the transport mode.

To give you a more intuitive understanding, let's look at the following figure to analyze why only the tunnel mode can be used in the Site-to-Site scenario:

As shown in the figure above, if the traffic sent from the initiator's intranet PC to the responder's intranet PC meets the gateway's interest flow matching condition, the initiator uses the transport mode for encapsulation:

• The IPSec session is established between the initiator and responder gateways.
• Since the transport mode is used, there will be no change in the IP header. The IP source address is 192.168.1.2 and the destination address is 10.1.1.2.
• After this data packet is sent to the Internet, its fate is doomed to be tragic. Why do we say that? Is it because its destination address is 10.1.1.2? This is not the root cause. The root cause is that the Internet does not maintain the routing of the enterprise network, so there is a high possibility that it will be discarded.
• Even if the data packet is not discarded in the Internet and luckily reaches the responder gateway, can we expect the responder gateway to perform decryption? Why? There is really no good evidence. The destination address of the data packet is 10.1.1.2 of the intranet PC, so it is forwarded directly.
• The most tragic thing is that the responder's intranet PC received the data packet, but because it did not participate in the IPSec session negotiation meeting and did not have the corresponding SA, the data packet could not be decrypted and was discarded.

We use this proof by contradiction to cleverly explain why the transport mode cannot be used in the Site-to-Site case. We also propose the necessary and sufficient conditions for using the transport mode: the interest flow must be completely within the IP address range of the initiator and responder. For example, in the figure, the initiator IP address is 6.24.1.2 and the responder IP address is 2.17.1.2. Then the interest flow can be source 6.24.1.2/32 and destination 2.17.1.2/32. The protocol can be arbitrary. If the source and destination IP addresses of the data packet are slightly different, sorry, please use the tunnel mode.

IPSec Negotiation

In addition to some IPSec protocol principles, we are more concerned with the content of the protocol involving solution formulation:

• Interest stream: IPSec is a protection measure that consumes resources. Not all traffic needs to be processed by IPSec. Traffic that needs to be protected by IPSec is called interest stream. The final negotiated interest stream is the intersection of the interest streams specified by the initiator and the responder. For example, the initiator specifies the interest stream as 192.168.1.0/24à10.0.0.0/8, and the responder's interest stream is 10.0.0.0/8à192.168.0.0/16, then the intersection is 192.168.1.0/24ßà10.0.0.0/8, which is the interest stream that will be protected by IPSec in the end.
• Initiator: The trigger of IPSec session negotiation. IPSec session negotiation is usually triggered by a designated interest stream. The triggering process is usually to match the source, destination address, protocol, and source and destination port numbers in the data packet with the pre-specified IPSec interest stream matching template such as ACL. If the match is successful, it belongs to the designated interest stream. The designated interest stream is only used to trigger negotiation. Whether it will be protected by IPSec depends on whether it matches the negotiated interest stream. However, in the usual implementation process, it is usually designed that the initiator's designated interest stream belongs to the negotiated interest stream.
• Responder: Responder is the receiver of IPSec session negotiation. The responder is a passive negotiation. The responder can specify the interest stream or not (completely specified by the initiator).
• The content negotiated between the initiator and the responder mainly includes: the confirmation of the identities of both parties and the key seed refresh cycle, the combination of AH/ESP and the algorithms used by each party, as well as the interest stream, encapsulation mode, etc.
• SA: The result of the negotiation between the initiator and the responder is the highly exposed SA, which usually includes the key and key lifetime, algorithm, encapsulation mode, initiator, responder address, interest stream, etc.

Let's take the most common IPSec tunnel mode as an example to explain the IPSec negotiation process:

The figure above describes the IPSec negotiation process triggered by the interest flow. Native IPSec does not have a negotiation process such as identity confirmation, and there are many defects in the solution, such as the inability to support identity confirmation and dynamic key update when the initiator's address changes dynamically. The IKE (Internet Key Exchange) protocol that appeared with IPSec is specifically used to make up for these shortcomings:

• The interest flow defined by the initiator is source 192.168.1.0/24 and destination 10.0.0.0/8, so the data packet sent by the initiator's intranet PC to the responder's intranet PC on the interface can be matched.
• If the conditions of the interest flow are met, the SA is checked on the forwarding interface and does not exist, expired, or unavailable, negotiation will be performed. Otherwise, the current SA is used to process the data packet.
• The negotiation process is usually divided into two stages. The first stage serves the second stage, and the second stage is the SA that actually serves the interest stream. The two stages of negotiation have different focuses. The first stage mainly confirms the correctness of the identities of both parties, and the second stage creates a specified security suite for the interest stream. The most significant result is that the interest stream in the second stage is encrypted in the session.

The security of IPSec is also reflected in the fact that the SA in the second phase is always unidirectional:

As can be seen from the figure above, when negotiating the second phase of SA, SA is directional. The SA used by the initiator to the responder and the SA of the responder to the initiator are negotiated separately. The advantage of this is that even if the SA in one direction is cracked, it will not affect the SA in the other direction. This design is similar to the two-way lane design.

Although IPSec is just a combination of 5 letters, the protocol functions it involves are numerous and the solutions are extremely flexible. This issue mainly introduces the basic principles of IPSec, and other aspects of IPSec will be introduced in the future.