I'm a tough guy, so please take this detailed description of IPSec architecture.

IP Security Architecture, referred to as IPSec, is a set of cryptography-based secure open network security protocols developed by the IETF IPSec Working Group in 1998. IPSec works at the IP layer and provides protection for the IP layer and its upper layer protocols.

IPSec provides security services such as access control, connectionless integrity, data source verification, anti-replay protection, confidentiality, and automatic key management. IPSec is independent of algorithms and allows users (or system administrators) to control the granularity of the security services provided. For example, an encrypted tunnel carrying all traffic can be created between two security gateways, or an independent encrypted tunnel can be established between each TCP connection between each pair of hosts that pass through these security gateways.

IPSec is below the transport layer and is transparent to applications and end users. When IPSec is installed on a router or firewall, there is no need to change the software settings in the user or server system. Even if IPSec is executed in the terminal system, upper-layer software such as applications will not be affected.

1. IPSec components

IPSec is a protocol suite defined by the Internet Engineering Task Force (IETF), which consists of a series of protocols, including Authentication Header (AH), Encapsulating Security Payload (ESP), Internet Security Association and Key Management Protocol (ISAKMP), Internet IP Security Domain of Interpretation (DOI), ISAKMP, Internet Key Exchange (IKE), IP Security Document Guide, OAKLE Key Determination Protocol, etc. They are published in the relevant documents of RFC2401 to RFC2412. Figure 2.3 shows the architecture, components and the relationship between the components of IPSec.

• AH (Authentication Header) and ESP (Encapsulating Security Payload): are the main bodies in the IPSec system, which define the protocol payload header format and the services they can provide, and also define the datagram processing rules. It is these two security protocols that provide network layer security services for datagrams. When processing datagrams, both protocols need to convert data according to a certain data conversion algorithm to ensure data security, including the algorithm, key size, algorithm program, and any information specific to the algorithm.
• IKE (Internet Key Exchange): IKE uses the ISAKMP language to define key exchange, which is a means of negotiating security services. The final result of the IKE exchange is a verified key and a security service based on the agreement of both parties in communication - the so-called "IPSec security association".
• SA (Security Association): A solution that specifically links security services/keys with communication data that needs to be protected. It ensures the correctness of IPSec datagram encapsulation and extraction, and links remote communication entities with IPSec data transmission that requires key exchange. In other words, SA solves the problem of how to protect communication data, what kind of communication data to protect, and who implements the protection.
• Policy: Policy is a very important component that has not yet become a standard. It determines whether two entities can communicate; if communication is allowed, what kind of data processing algorithm is used. If the policy is not defined properly, it may lead to the inability of the two parties to communicate normally. The issues related to policy are representation and implementation. "Representation" is responsible for the definition, storage and retrieval of policies, while "implementation" emphasizes the application of policies in actual communication.

2. How IPSec works

IPSec is designed to provide high-quality, interoperable, cryptographic-based security for IPv4 and IPv6 data. IPSec achieves these goals by using two communication security protocols: Authentication Header (AH) and Encapsulating Security Payload (ESP), as well as key management processes and protocols such as the Internet Key Exchange (IKE) protocol.

The IP AH protocol provides data source authentication, connectionless integrity, and an optional anti-replay service. The ESP protocol provides data confidentiality, limited data stream confidentiality, data source authentication, connectionless integrity, and anti-replay services. There are two operating modes for both AH and ESP: transport mode and tunnel mode. The IKE protocol is used to negotiate the cryptographic algorithms used by AH and ESP, and to place the keys required by the algorithms in the appropriate locations.

The protocol used by IPSec is designed to be algorithm-independent. The choice of algorithm is specified in the Security Policy Database (SPD). IPSec allows users and administrators of a system or network to control the granularity of security services provided. By using Security Associations (SAs), IPSec can differentiate the security services provided to different data flows.

IPSec itself is an open system. With the advancement of network technology and the emergence of new encryption and verification algorithms, IPSec can meet the future needs for information security by continuously adding new security services and features. With the continuous advancement of Internet technology, IPSec, as a network layer security protocol, is also constantly improving and adding new functions. In fact, the system expansion problem was considered when the IPSec framework was designed. For example, the ESP and AH documents define the protocol, the format of the header, and the services they provide, as well as the datagram processing rules, but do not specify the specific data processing algorithms used to implement these capabilities. The default and mandatory encryption MACs of AH are HMA-CMD5 and HMA-CSHA. In the implementation plan, other encryption algorithms such as DES-CBC, CAST-CBC, and 3DES-CBC can be used as encryptors.

3. IPSec Mode

The IPSec protocol (including AH and ESP) can be used to protect a complete IP payload or the upper layer protocol of a certain IP payload. These two aspects of protection are provided by two different "modes" of IPSec: transport mode and tunnel mode.

• Transport mode: In transport mode, a special IPSec header is inserted between the IP header and the upper layer protocol header. Transport mode protects the payload of the IP packet or the upper layer protocol (such as TCP, UDP and ICMP), as shown in Figure 2.4. In general, transport mode is only used for secure communication between two hosts.
• Tunnel mode: Tunnel mode provides protection for the entire IP packet. As shown in Figure 2.5, the entire IP packet to be protected needs to be encapsulated into another IP datagram, and an IPSec header is inserted between the outer and inner IP headers. All original or inner packets are transmitted from one end of the IP network to the other through this tunnel. Routers along the way only check the outermost IP header and do not check the original inner IP header. Since a new IP header is added, the destination address of the new IP message may be inconsistent with the original one.

In the implementation of Gigabit network encryption engineering, what we need is to implement a security gateway device based on the IPSec protocol. In order to ensure the confidentiality of the data, consider using ESP encapsulation in tunnel mode. Since the IKE protocol is implemented by software, and this article focuses on the hardware implementation of IPSec, this article will not introduce the IKE protocol.

4. IPSec Implementation

IPSec can be implemented and deployed simultaneously in hosts, routers or firewalls (creating a security gateway). Users can decide where to implement it based on their needs for security services. IPSec can be implemented in three ways: integrated, BITS and BITW.

• Integration method: Integrate IPSec into the original implementation of the IP protocol, which requires processing the IP source code and is suitable for implementation in hosts and security gateways.
• "Blocks in the stack (BITS)" method: IPSec is inserted as a "wedge" between the original IP protocol stack and the link layer. This does not require processing the IP source code and is suitable for upgrading and modifying the original system. This method is usually used in the host mode.
• "Blocks in the Wire (BITW)" approach: This is the approach used in this article to implement IPSec, which implements IPSec in a device that is directly connected to a router or host device. When used to support a host, it is very similar to the BITS implementation, but when supporting a router or firewall, it must act as a security gateway.

5. IPSec protocol processing

IPSec processing is divided into two categories: outbound processing and inbound processing.

(1) Outbound processing

During outbound processing, the data packet flows from the transport layer into the IP layer. The IP layer first extracts the relevant parameters of the IP header, searches the SPDB database, and determines which security services should be provided for this packet. The input to the SPDB is the "selector" of the source address and destination address in the transmission header. The output of the SPDB is the policy result queried based on the "selector", which may occur in the following situations:

Discard the packet. The packet will not be processed and is simply discarded. Bypass security services. In this case, the IP packet is not processed and is sent out as a normal IP packet. Apply security services. In this case, you need to continue with the following processing.

If the policy output of the SPDB indicates that the data packet requires security protection, then the SADB is queried to verify whether the SA associated with the connection has been established. The result of the query may be one of the following two situations: If the corresponding SA already exists, the query to the SADB will return a pointer to the SA; If the corresponding SA cannot be found, it means that the secure communication connection to which the data packet belongs has not been established, and IKE will be called for negotiation to establish the required SA. If the required SA already exists, the SPDB structure contains a pointer to the SA or SA bundle (determined by the policy). If the query output of the SPDB stipulates that IPSec must be applied to the data packet, the data packet is not allowed to be transmitted before the SA is successfully created.

The SA obtained from the SADB must be processed. The processing process is as follows:

• If the SA's soft lifetime has expired, IKE is called to establish a new SA.
• If the hard lifetime of an SA expires, the SA is deleted.
• If the sequence number overflows, IKE is called to negotiate a new SA.

After the SA processing is completed, the next step of IPSec processing is to add the appropriate AH or ESP header and start processing the data packet. This involves the encryption of the payload data, calculation and verification, etc., which will be described in detail below. SA contains all the necessary information and is arranged in order so that the IPSec header can be constructed in the correct order. After the IPSec header is constructed, the generated datagram is sent to the original IP layer for processing, and then the datagram is sent.

(2) Enter processing

During the inbound processing, after receiving the IP packet, if the packet does not contain an IPSec header at all, IPSec will consult the SPDB and determine how to handle the packet based on the security services provided. Because if a specific communication requires IPSec security protection, any incoming packet that does not match the SPDB definition of the communication protected by IPSec should be discarded. It will use the "selector" field to search the SPDB database. The output of the policy may be the following three situations: discard, bypass or apply. If the output of the policy is discard, the data packet will be abandoned; if it is applied, but the corresponding SA is not established, the packet will also be discarded; otherwise, the packet will be passed to the next layer for further processing.

If the IP packet contains an IPSec header, the IPSec layer will process the packet. IPSec extracts the SPI, source address, and destination address from the data packet and organizes them into

After IPSec completes the policy verification, it will strip off the IPSec header and pass the packet to the next layer. The next layer is either a transport layer or a network layer. If the data packet is IP [ES [PTCP]], the next layer is the transport layer; if the packet is IP [AH [ESP [TCP]]], the next layer is still the IPSec layer.

6. Authentication Header (AH) Protocol

(1) AH’s objectives

In the IP protocol, the authentication mechanism used to provide integrity of IP data packets is very simple. The IP header uses the checksum field in the header to ensure the integrity of the IP data packet. The checksum is just the inverse of the cumulative sum calculated for each 16 bits of the IP header. This does not provide much security because the IP header can be easily modified. The checksum can be recalculated for the modified IP header and used to replace the previous checksum. In this way, the receiving host cannot know that the data packet has been modified.

The purpose of designing the Authentication Header (AH) protocol is to increase the security of IP data packets. The AH protocol provides connectionless integrity, data origin authentication, and anti-replay attack services. However, AH does not provide any confidentiality services, that is, it does not encrypt the protected data packets. The role of AH is to provide high-strength cryptographic authentication for IP data streams to ensure that modified data packets can be checked. AH uses a message authentication code (MAC) to authenticate IP. MAC is different from a hash function because it requires a key to generate a message digest, while a hash function does not require a key. The commonly used MAC is HMAC, which is used in conjunction with any iterative cryptographic hash function (such as MD5, SHA-1, Tiger, etc.) without modifying the hash function. Since a key is required to generate the message digest of the IP data packet, the two communicating parties of IPSec need to share the same authentication key. This key is provided by the SA information of both parties.

(2) AH protocol packet format

AH is only used to ensure that the received data packet is not modified during transmission, that it is sent by the party that requested it, and that it is a new non-replayed data packet. When AH is used in the transport mode, it protects end-to-end communication. The end point of the communication must be the IPSec end point, so it is not considered in the VPN tunnel mode we are studying. The packet format of the AH protocol tunnel mode is shown in Figure 2.6:

• Next header (8 bits): indicates the protocol type of the next payload.
• Payload length (8 bits): AH payload length.
• Reserved (8 bits): For future use.
• Security Parameter Index SPI (32bit): It is a 32-bit integer. It uniquely identifies the security association (SA) of the data stream to which a data packet belongs together with the source address or destination address and the PSEC protocol (AH or ESP). SPI values ​​1 to 255 are reserved by IANA for future use; 0 is reserved for local and specific implementations. Therefore, the current valid SPI values ​​range from 256 to 2³²-1.
• Sequence number (32bit): This contains a 32-bit unsigned integer as a monotonically increasing counter to prevent replay of packets. Replay means that the packet is intercepted and resent by the attacker. If the receiver has enabled the anti-replay attack function, it will use a sliding receive window to detect replayed packets. The specific sliding window varies with different PSEC implementations, and generally has the following functions. The minimum window length is 32 bits. The right edge of the window represents the maximum sequence number that has been received and verified to be valid for a specific SA. Packets with sequence numbers less than the left edge of the window will be discarded. The packet with the sequence number value within the serial port is compared with the list of received packets within the window. If the sequence number of the received packet is within the window and is new, or the sequence number is greater than the right edge of the window and is valid, the receiving host continues to process the calculation of the authentication data.
• Authentication data: This is a variable length field (must be an integer multiple of 32-bit words). It contains the authentication data of the packet, which is called the integrity check value (ICV) of this packet. The available algorithms for calculating ICV vary depending on the IPSEC implementation; however, in order to ensure interoperability, AH forces all IPSec to include two MACs: HMAC-MD5 and HMAC-SHA-I.