Processing of packets sent and received by Spd, sad, traffic selector, and Ike

There are two important databases in the IPSec Security System. One is the SPD-security policy database, and the other is the sad-Security Association database. As the name suggests, Spd defines several policies to explain how each IP data stream should be processed, whether it is passthrough, discarded, or encrypted by IPSec. Sad is responsible for saving the established Sa-related information, such as SA parameters, such as encryption algorithms, authentication algorithms, and survival time.

The following example illustrates the association between them. The network structure is as follows:

Description:

The device 10.0.68.5 is in the LAN 10.0.68.0/24 of spoke-2-East. It wants to communicate with 10.1.1.5, a device in the VPN-GW1-EAST's LAN 10.1.1.0/24.

The communication process is as follows:

1. When an IP packet is sent from 10.0.68.5 to the destination address 10.1.1.5, the packet first reaches the vrospospoke-2-east through the LAN device. The configuration information above determines that the packet is routed to the Internet through the network interface serial0/0.

2. Before a data packet is routed out, the router first checks the spd of the serial0/0 interface.

The content of SPD is as follows:

Study this SPD. Each row represents a SPD entry. Local IP/local port/remote IP/remote port/protocol are all traffic selector. What policies does action mean for IP streams that meet the conditions? Is it discard/bypass, or is it encrypted using IPsec? Policy indicates the algorithm that should be recommended during SA negotiation once IPsec Encryption is adopted. Currently, all SA entries are empty because no SA has been created.

After careful observation, we can find that each traffic selector has a sharing? What does this mean? Rfc4301 requires that each selector contains a PfP flag (populate from packet ). It can be set to true or false. If this flag is set to true, it indicates that the traffic selector payload in packet is used as the selector when a SA is created. Otherwise, the selector in SPD is used. For example, 10.0.68.5 wants 10.1.1.5 to send an HTTP request. According to SPD, it satisfies the rule that the top index is 9. Because the SA does not exist, the necessary SA will be generated after the ike_auth switch. When a new SA is generated, the local in rule 9 is found.
The PFP flag of IP/remote IP is false, that is, sa sharing is allowed. The traffic selector in rule 9 is used to generate a shared SA. All TCP streams from 10.0.68.5 to 10.1.1.0/24 are encrypted using the newly generated SA. Conversely, if PFP is true, that is, sa sharing is not allowed, traffic selector, which is negotiated in the traffic selector payload in the ike_auth message, will be used when the SA is generated. If the TSI value specified in traffic selector payload is 10.0.68.5 and the TSR value is 10.1.1.5, the newly generated SA only provides IPSEC protection for TCP data streams between 10.0.68.8 and 10.1.1.5.

In summary, PFP flag describes whether to generate a SA using the traffic selector in the SPD entry or the traffic selector in the traffic selector payload of the ike_auth/ike_create_child message. If the former is used, it means that each rule in the SPD will only correspond to a pair of SA, so that a pair of SA from 10.0.68.5 and 10.1.1.0/24 network segments will be used. If the latter is used, the new SA generated may only correspond to a subset described in the SPD entry. In this case, there may be a dedicated SA between 10.0.68.5 and 10.1.1.5, however, communication between 10.0.68.5 and 10.1.1.8 may create another pair of SA. In this way, a SPD
The policy corresponding to the entry may generate multiple SA instances.

Here, we find that there is a pair of sad entry pointers in the SPD entry. However, the definition of the SPD entry structure in rfc4301 does not require that the SPD entry contain the sad entry pointer. The SPD table here is only implemented in one way. In the specific implementation, this pointer is completely unavailable. After learning about the policy that needs to be adopted for an IP stream from the SPD, go to the sad to check whether there is a corresponding SA. The pointer containing the sad entry in SPD can improve the efficiency. However, if one SPD entry corresponds to multiple SAS, a mechanism is required to find the most matched one from multiple SAS entry pointers.

Sad:

SPD is a policy database that describes the policies that should be adopted for each IP datagram, namely passthrough, discard, or perform IPSec encryption and decryption. It also provides negotiation parameters for SA establishment, such as cipher suites and survival time. Newly generated SA is inserted into sad. Whenever a packet is sent or received, if the policy for it is IPSec, it is necessary to find the corresponding SA in the sad, according to the parameters provided in the SA, encrypt and decrypt data packets, generate checksum, and encapsulate data packets into AH/ESP.

3. So far, we have learned from Spd and sad that the SA responsible for the IP datagram has not yet been established. Spoke-2-East will first initiate the first Ike negotiation request to the remote VPN-GW1-East. After successful negotiation, the two security gateways generate an IPSec SA for communication between 10.0.68.5 and 10.1.1.0/24.

4. When the VPN-GW1-East receives an encrypted packet. It first uses the external destination address, esp Protocol number, and ESP header SPI as an index to retrieve SA from sad. If found, use the SA parameter to decrypt the data packet, and then apply the SPD rule to the decrypted data packet. The internal IP address is used because the data packet has been decrypted.