IPSec is not a separate protocol, but a set of network security protocol suites, including network authentication protocol AH (Authentication Header, authentication header), ESP (Encapsulating Security Payload, encapsulation load) and key management protocol IKE (Internet Key Exchange, Internet Key exchange) and some algorithms for user network authentication and encryption.

IPSec working modes are divided into two types: transport mode (transport) and tunnel mode (tunnel). To put it simply, the transmission mode is that the original Layer 2 data packets are no longer appended with Layer 2, 3, and 4 headers. The tunnel mode is that the original Layer 2 data packets are encapsulated through the protocol tunnel and are added with Layer 2, 3, and 4 headers. The tunnel mode of IPSec is to add layer 2, 3, and 4 headers to the original IP address. The data packet is encapsulated with a layer of IP header, so IPSec is often called the three-layer tunneling protocol. The following will give you a detailed understanding of some of these specific protocols, as well as the implementation of traversal NAT, which plays an important role in the practical application of IPSec protocol.

Part 01. Security protocol—AH protocol 

The AH protocol is an IP-based transmission protocol with protocol number 51. The specific working method is to add an AH header after the standard IP header of each data packet:

The sender of the AH protocol will perform hash calculation on the data packet and authentication key. After the receiver receives the message, it will perform hash calculation according to the same algorithm and compare it with the original calculation result. If it is inconsistent, it can be inferred that the data packet is in the transmission process. been modified or destroyed. In this way, data source authentication and data integrity verification can be provided. It is worth mentioning that the integrity check range of the AH protocol is the entire IP message.

There are several important fields in the AH packet header that deserve attention: the security parameter index (SPI) is used to uniquely identify the IPSec security association, and the sequence number uniquely identifies each data packet, which can be used to prevent replay attacks.

Part 02. Security protocol—ESP protocol  

Like the AH protocol, the ESP protocol is also an IP-based transport layer protocol with protocol number 50. The specific working method is to add an ESP header after the IP header of each data packet. It is worth noting that an ESP tail (ESP Tail and ESP Auth Data) is also appended to the end of the data packet, and there is also a little Different from the AH protocol, the ESP protocol only encrypts the payload of the IP packet and does not encrypt the IP header.

Similar to the AH protocol, the ESP packet header also has two fields, the security parameter index (SPI) and the sequence number. Moreover, the authentication algorithms of the AH protocol and the ESP protocol are the same.

The specific comparison between the AH protocol and the ESP protocol is as follows:

Summary: AH protocol cannot provide data packet encryption function, and the verification scope of ESP protocol does not include IP header. Therefore, in scenarios with high security requirements, you can consider using AH protocol and ESP protocol together.

Part 03,   IKE protocol 

Simply put, the IKE protocol is a protocol for dynamically negotiating IPSec tunnels. It can complete identity authentication, key exchange, and generate IPSec SA. During the negotiation process, the specific use of AH protocol or ESP protocol encapsulation and identity authentication for data packets is determined.

The IKE protocol currently has two versions: IKEv1 and IKEv2. Based on v1, IKEv2 not only simplifies the SA negotiation process and improves negotiation efficiency, but also fixes many recognized cryptographic security vulnerabilities and improves security performance. , so the actual application of IKEv2 is more widespread.

Taking IKEv2 as an example, the first pair of IPSec SAs can be negotiated and established through the initial exchange, which involves two exchanges of four messages, including negotiation of parameters such as encryption and verification algorithms, generating a shared key, and completing identity authentication and message authentication. If multiple pairs of IPSec SAs need to be created, they can be negotiated through the exchange process of creating sub-SAs. At the same time, some control information is transmitted during the negotiation process, such as error messages or notification messages. This information is completed through notification exchanges.

Part 04, NAT traversal 

The IPSec protocol can be widely used. In addition to providing secure and encrypted transmission, another important reason is that it can realize NAT traversal. This is extremely important in live network transmission, because public network IP resources are limited and most devices The public network IP resources are shared to transmit and exchange messages after NAT conversion, so NAT traversal is extremely important in existing network applications.

As described above about the characteristics of the AH protocol and ESP protocol, we found that the AH protocol cannot traverse NAT because NAT will modify the IP header of the message, but the AH integrity check is based on the entire IP message, so the AH protocol IPSec cannot traverse NAT. The integrity check of ESP messages does not include the IP header, and IP address conversion will not destroy the ESP hash value. Therefore, in a NAT scenario where only IP conversion is performed, ESP protocol encapsulation supports NAT traversal. But many times, the public IP is shared, so NAT conversion not only needs to convert the IP, but also needs to convert the port. However, the ESP protocol encrypts the IP payload, making it impossible to modify the port number. This is also the problem with many IP in IP The fundamental reason why the tunnel cannot traverse NAT is to add a UDP header - NAT-T (NAT Traversal). The source and destination port numbers are both 4500.

The NAT-T tunnel can solve the problem of IPSec traversing NAT, but there are also the following two problems after traversing NAT: First, the problem of identity authentication and IP address reuse after traversing NAT. In the current IP network, IP is the identity identifier, but the IP will change after NAT. Currently, in China, strings are mainly used to replace IP addresses as identity identifiers, so that they are not affected by NAT. Second, the ESP protocol is an IP-based protocol. When there are multiple ESP applications behind the NAT gateway and the addresses are reused, reverse mapping cannot be performed based only on the IP protocol number, and the ESP protocol must be changed. This will be specifically reflected in the NAT-T process. Below we will elaborate on the NAT-T process .

First determine whether both parties support NAT-T. When NAT traversal is enabled, the vendor ID payload identifying the NAT-T capability will be sent during the IKE negotiation process to check whether the communicating parties support NAT-T. Only when both parties include the payload in their respective messages will the subsequent Perform relevant NAT-T negotiations. The second step is to determine whether there is a NAT device on the link. During the IKE negotiation, a NAT-D (NAT Discovery) payload will be sent. This payload is used to detect NAT devices. Both parties will send the hash value of the source and destination IP and port to the other party and store it in the payload. If an error occurs during the transmission, Change, the hash value will change accordingly, and judging the hash value can determine whether there is NAT conversion in the link. The last step is ESP processing . Under the premise of the first two steps, after the NAT gateway is discovered, the port number of subsequent IKE messages is converted to 4500.

Although the above technology can achieve NAT traversal, it also has certain limitations: using the NAT-T function will increase approximately 200 bytes of overhead during the IKE negotiation process, and will also increase approximately 20 bytes of overhead during data transmission; At the same time, the AH protocol cannot be used, which will reduce security to a certain extent; NAT equipment cannot guarantee that a fixed IP and fixed port will always provide access mapping for internal hosts, so IPSec must be able to automatically detect changes to ensure that communication is always smooth.

Part 05, Postscript 

Since IPSec was developed in 1990, it has been used for more than 30 years. The development of technology has become increasingly mature after generations of accumulation, and the basic exchange process is relatively complete. The future development direction is likely to be in authentication and encryption algorithms. . The US NIST also released a special publication "IPSec VPNs Guide" in 2020. The article pointed out that the IETF is focusing on researching various IKE and IPSec extension issues. It also introduced implicit IV in multicast and group authentication, ESP, Post-quantum key exchange and other efforts. In the future, we will pay close attention to the latest IPSec technology in a timely manner, apply it in actual production and work, and contribute to China Mobile's new network architecture.